Patches item #1583880, was opened at 2006-10-24 18:38
Message generated for change (Comment added) made by gustaebel
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1583880&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.6
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Lars Gust�bel (gustaebel)
Assigned to: Nobody/Anonymous (nobody)
Summary: tarfile.py: better use of TarInfo objects with longnames
Initial Comment:
When a TarInfo object with a long name is added to a
TarFile, the .name attribute is garbled during the
special processing involved with long names. This is
true for both posix and gnu mode and has historical
"design" reasons.
In posix mode, a long name is split in two. TarInfo's
prefix attr gets the first part, the name attr the
second one.
In gnu mode, a long name is truncated up to LENGTH_NAME
(100) chars and stored the TarInfo's name attr.
So, if you open a TarFile for writing, add a few files
with long names to it and call the getnames() method
for that still open file, the names returned are all
cut. The getmember() method will not work, because all
names have changed.
On top of that, if a user adds a TarInfo object to a
TarFile it is not copied. So, it is undefined what
happens if the user uses the same TarInfo object
several times with changed attributes. The problem
described in bug #1583537 (now deleted) was partly
caused by this.
The attached patch makes it possible to use the same
TarInfo object several times by copying it in
TarFile.addfile(), removes the (undocumented)
TarInfo.prefix attr and leaves TarInfo.name alone.
I think this should be backported to 2.5 as well.
----------------------------------------------------------------------
>Comment By: Lars Gust�bel (gustaebel)
Date: 2006-10-25 21:57
Message:
Logged In: YES
user_id=642936
I spent some more time on the patch and went a bit further.
I moved the _create_gnulong() method from TarFile to
TarInfo, so TarInfo.tobuf() is now able to create GNU
extensions by itself. The distinction between posix and
non-posix mode is very clear in the code now. The
TarFile.addfile() method is cleaner as well.
The only drawback might be that the _dbg calls ("Created GNU
extension ... ") are gone now.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1583880&group_id=5470
_______________________________________________
Patches mailing list
[email protected]
http://mail.python.org/mailman/listinfo/patches
