With all the tools I've used, the target of a symlink appears to be relative to the actual symlink entry. Fix this.

Apparently you were in quite a hurry when you filed this bug report.

- What is the exact problem and how does it manifest itself?
- Any helpful details (tracebacks, output)?
- Is there a testcase or example code you can provide?
- Which other tools are you talking about?
- Your patch is faulty (upperdir is undefined).
- The patch does not apply to neither r27 tag nor release27-maint branch although you claim that 2.7 is affected.
- Which exact Python version are you using on what platform?
- Oh, and a little more politeness wouldn't hurt.

Okay, so please ask again. I am curious to see what you've found.

Oh man, attaching the wrong diff and getting the diff wrong.

The issue I found with Python 2.7:

when creating a simple link in tar:

$ mkdir tar_test
$ cd tar_test
$ touch one
$ ln -s one two
$ cd ..
$ tar czf tar_test.tgz tar_test

It seems obvious that there would be a relative link in the tar file:

-rwxrwxrwx jstpierre/me 2010-11-02 10:57:15 tar_test/two -> one

Unfortunately, as far as I can tell, tarfile treats this as an absolute path, and fails when extracting:

>>> tf.extractfile("tar_test/two")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python2.6/tarfile.py", line 2122, in extractfile
    tarinfo))
  File "/usr/lib/python2.6/tarfile.py", line 2105, in extractfile
    if tarinfo.isreg():
AttributeError: 'NoneType' object has no attribute 'isreg'

I was trying to fix that.

Uh, I just noticed the "python2.6" in the traceback.

Looks like I *was* using 2.6 because Cygwin decided
to downgrade for some reason.

Uh, sorry about that.

Okay, this bug has been fixed in the 2.7 series. Python 2.6 is now in security-fix-only mode which means that there will not be a fix for it.

Therefore, I close this issue.