[Patches] [ python-Patches-1509889 ] tarfile stops iteration with some longfiles

SourceForge.net noreply at sourceforge.net
Wed Jun 21 19:47:41 CEST 2006


Patches item #1509889, was opened at 2006-06-21 11:44
Message generated for change (Settings changed) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1509889&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Library (Lib)
Group: Python 2.4
>Status: Closed
>Resolution: Out of Date
Priority: 5
Submitted By: Faik Uygur (faik)
Assigned to: Nobody/Anonymous (nobody)
Summary: tarfile stops iteration with some longfiles

Initial Comment:
tarfile.py in python 2.4.3 version has a bug that makes 
it to stop iteration while reading members. 

If a file's name is longer than 100 bytes, after 
reading ././@LongLink header of the file in the tar 
archive, tarfile tries to read the actual header. But if the 
100 byte of the file's name ends with "/" and it is a 
regular file (type is a file type). Tarfile changes it's type 
to a directory by thinking that it is some old tar archive 
format's directory member (because it seems to end 
with a "/").

I created a tar archive to test this case. You can find it 
in the attachments.

My test code does this:

#!/usr/bin/python
import tarfile
import sys
tar = tarfile.open(sys.argv[1], "r")
tar.list()

If I run it with the prepared tar file, i get this output:

faik at pardus tmp $ ./tarlist.py longfiles.tar
-rwxr-xr-x faik/users          0 2006-06-21 13:03:59 
this.is.a.very.long.directory.name/
-rwxr-xr-x faik/users          0 2006-06-21 13:06:17 
this.is.a.very.long.directory.name/this.is.another.very.long.directory.name/
-rwxr-xr-x faik/users          0 2006-06-21 13:08:21 
this.is.a.very.long.directory.name/this.is.another.very.long.directory.name/and.this.is.another.one/
-rw-r--r-- faik/users         19 2006-06-21 13:08:41 
this.is.a.very.long.directory.name/this.is.another.very.long.directory.name/and.this.is.another.one/NEWS

But if I run tar(1) with tvf options, i get this output:

faik at pardus tmp $ tar tvf longfiles.tar
drwxr-xr-x faik/users        0 2006-06-21 13:03:59 
this.is.a.very.long.directory.name/
drwxr-xr-x faik/users        0 2006-06-21 13:06:17 
this.is.a.very.long.directory.name/this.is.another.very.long.directory.name/
drwxr-xr-x faik/users        0 2006-06-21 13:08:21 
this.is.a.very.long.directory.name/this.is.another.very.long.directory.name/and.this.is.another.one/
-rw-r--r-- faik/users       19 2006-06-21 13:08:41 
this.is.a.very.long.directory.name/this.is.another.very.long.directory.name/and.this.is.another.one/NEWS
-rw-r--r-- faik/users       18 2006-06-21 13:10:10 
this.is.a.very.long.directory.name/this.is.another.very.long.directory.name/and.this.is.another.one/COPYING
-rw-r--r-- faik/users       26 2006-06-21 13:09:05 
this.is.a.very.long.directory.name/this.is.another.very.long.directory.name/and.this.is.another.one/README

tarfile.py ends iteration with this member 
file: "this.is.a.very.long.directory.name/this.is.another.very.long.directory.name/and.this.is.another.one/NEWS".
Because the full directory path name length that 
contains the NEWS file is exactly 100 bytes long.

There is also an attachment for the fix of the bug. 


----------------------------------------------------------------------

>Comment By: Georg Brandl (gbrandl)
Date: 2006-06-21 17:47

Message:
Logged In: YES 
user_id=849994

This is fixed in SVN, you can try the 2.5 beta to verify it.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1509889&group_id=5470


More information about the Patches mailing list