homepage

I have a tarfile with relative paths. The tail of tar tvf looks like this:
-rw-r--r-T nobody/nobody 1356 2012年02月28日 19:25 s/772
-rw-r--r-- nobody/nobody 1304 2012年02月28日 19:25 s/773
-rw-r--r-- nobody/nobody 1304 2012年02月28日 19:25 s/774
-rw-r--r-- nobody/nobody 1304 2012年02月28日 19:25 s/775
lrw-r--r-- nobody/nobody 0 2012年02月28日 19:25 final -> s/772
The docs say:
 TarFile.extractfile(member)
 Extract a member from the archive as a file object. member 
 may be a filename or a TarInfo object. If member is a regular
 file, a file-like object is returned. If member is a link, a 
 file-like object is constructed from the link’s target.
However, what I'm getting is this:
 KeyError: "linkname '/s/772' not found"
It's appending a "/". Why?
Well, in tarfile.py:
 if tarinfo.issym():
 # Always search the entire archive.
 linkname = os.path.dirname(tarinfo.name) + "/" + tarinfo.linkname
 limit = None
Here, os.path.dirname(tarinfo.name) returns '', and then the "/" is appended, giving an incorrect result.
One solution would be:
 linkname = os.path.join(os.path.dirname(tarinfo.name),tarinfo.linkname)
but I don't think that works on platforms where os.sep is not "/", since tar will want "/" in any case. But that's the correct logic.
I'm filing this against 2.7, but the same issue exists in 3.2.
A work-around in end-user code is to call Tarfile.getmember(filename), check if the result issym(), and replace the result with Tarfile.getmember(tarinfo.linkname). But since the extractfile function is documented as following symlinks, that should not be necessary.
This bug isn't commonly encountered because by convention tarfiles usually contain a subdirectory and everything goes in that. But we should do the right thing.