classification
Title: tarinfo should use relative symlinks
Type: Stage:
Components: Library (Lib) Versions: Python 2.6
process
Status: closed Resolution: fixed
Dependencies: Superseder:
Assigned To: lars.gustaebel Nosy List: Benjamin.Root, eric.araujo, lars.gustaebel, magcius
Priority: normal Keywords: patch

Created on 2010-11-02 05:58 by magcius, last changed 2013-10-14 17:48 by Benjamin.Root. This issue is now closed.

Files
File name Uploaded Description Edit
tarinfo-10292.diff magcius, 2010-11-02 05:59 Patch to fix this.
Messages (7)
msg120208 - (view) Author: Jasper St. Pierre (magcius) Date: 2010-11-02 05:58
With all the tools I've used, the target of a symlink appears to be relative to the actual symlink entry. Fix this.
msg120224 - (view) Author: Lars Gustäbel (lars.gustaebel) * (Python committer) Date: 2010-11-02 14:18
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.
msg120228 - (view) Author: Jasper St. Pierre (magcius) Date: 2010-11-02 14:59
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.
msg120230 - (view) Author: Jasper St. Pierre (magcius) Date: 2010-11-02 15:28
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.
msg123421 - (view) Author: Lars Gustäbel (lars.gustaebel) * (Python committer) Date: 2010-12-05 12:21
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.
msg199931 - (view) Author: Benjamin Root (Benjamin.Root) Date: 2013-10-14 17:38
What was the issue number for the python2.7 fix? I think I have hit upon this issue myself and I need to see if I need to file a new report.
msg199935 - (view) Author: Benjamin Root (Benjamin.Root) Date: 2013-10-14 17:48
To clarify, the bug is resolved in py2.7 -- for the most part. I think I have come upon an edge-case where if the archived symbolic link refers to a file not contained in a subdirectory, say: "foo.txt -> foobar.txt", extracting "foo.txt" would result in an exception: 'KeyError: "linkname '/foobar.txt' not found"'.
History
Date User Action Args
2013-10-14 17:48:03Benjamin.Rootsetmessages: + msg199935
2013-10-14 17:38:53Benjamin.Rootsetnosy: + Benjamin.Root
messages: + msg199931
2010-12-05 12:21:55lars.gustaebelsetstatus: open -> closed
resolution: fixed
messages: + msg123421

versions: + Python 2.6, - Python 2.7
2010-11-20 23:03:02eric.araujosetnosy: + eric.araujo
2010-11-02 15:28:09magciussetmessages: + msg120230
2010-11-02 14:59:28magciussetmessages: + msg120228
2010-11-02 14:18:21lars.gustaebelsetmessages: + msg120224
2010-11-02 06:44:05loewissetassignee: lars.gustaebel

nosy: + lars.gustaebel
2010-11-02 05:59:07magciussetfiles: + tarinfo-10292.diff
keywords: + patch
2010-11-02 05:58:10magciuscreate