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.

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.

Logged In: YES 
user_id=849994

Committed as rev. 52524, 52525 (2.5).