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.