[Patches] [ python-Patches-1695229 ] tarfile bug when opening a file directly

SourceForge.net noreply at sourceforge.net
Fri Apr 6 23:41:41 CEST 2007


Patches item #1695229, was opened at 2007-04-05 15:49
Message generated for change (Comment added) made by draghuram
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1695229&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Library (Lib)
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Arve Knudsen (arve_knudsen)
Assigned to: Lars Gustäbel (gustaebel)
Summary: tarfile bug when opening a file directly

Initial Comment:
The tarfile.open function supports two ways of opening a file, either indirectly by specifying its name (parameter 'name') or by passing an open file object (parameter 'fileobj'). If one only passes a file object however an exception is raised, since on line 1047 TarFile.__init__ passes the filename to os.path.abspath, regardless of whether it is None or not.

----------------------------------------------------------------------

Comment By: Raghuram Devarakonda (draghuram)
Date: 2007-04-06 17:41

Message:
Logged In: YES 
user_id=984087
Originator: NO


I completely agree that it can be worked around very simply and so may not
merit a fix in the current release. May be, a simple doc change would
suffice. But I fail to understand how fixing this issue in 2.5 would break
some existing code. There will be no current code that uses open without
"name" (as that results in exception) and allowing that usage should not
break any code. No? 

----------------------------------------------------------------------

Comment By: Lars Gustäbel (gustaebel)
Date: 2007-04-06 16:14

Message:
Logged In: YES 
user_id=642936
Originator: NO

I admit that the docs for 2.5 lack explicitness in this aspect. It is not
explicitly said that fileobj may be passed without a name argument.
However, in the method signature name is listed as optional. If no name
argument is passed I would say behaviour is *undefined* atm. I may be too
pedantic, but:

1. It is perfectly simple to work around this problem.
2. It is just a question of code-niceness.
3. It is already fixed for the next major release.

I do not like to take the risk to break someone's code with a bugfix
release.


----------------------------------------------------------------------

Comment By: Raghuram Devarakonda (draghuram)
Date: 2007-04-06 14:55

Message:
Logged In: YES 
user_id=984087
Originator: NO


Hi,

I may be missing something here but the 2.5 document lists "name"
parameter as optional. So if not using it results in an exception, it
should be a bug. Right? If there is a mention in the document that "name"
must be passed (directly or indirectly), can you please point that out? As
I said, I might have missed it. If this is accepted as a bug, then it alone
can be fixed instead of back porting entire 54335 changes?. Of course, I
don't know how easy it is to fix this issue alone and if is closely
intertwined with those changes, then it doesn't make sense to fix this
issue separately in 2.5.

Thanks,
Raghu.


----------------------------------------------------------------------

Comment By: Lars Gustäbel (gustaebel)
Date: 2007-04-06 14:03

Message:
Logged In: YES 
user_id=642936
Originator: NO

I'm afraid not. This is a new feature not a bugfix. The 2.5 behaviour is
not a bug, it is documented. Backporting the new behaviour would make it
necessary to change the documentation, too. Because of Python release
policy and 2.5.1 being a bugfix release, this cannot go in, I'm afraid. You
must wait for the 2.6 release and work around this in the meantime. Sorry.

----------------------------------------------------------------------

Comment By: Arve Knudsen (arve_knudsen)
Date: 2007-04-06 06:23

Message:
Logged In: YES 
user_id=1522083
Originator: YES

Can we expect a fixed 2.5 release soon?

----------------------------------------------------------------------

Comment By: Lars Gustäbel (gustaebel)
Date: 2007-04-06 06:09

Message:
Logged In: YES 
user_id=642936
Originator: NO

This was fixed with rev. 54335 (trunk) as part of a larger changeset.

----------------------------------------------------------------------

Comment By: Arve Knudsen (arve_knudsen)
Date: 2007-04-06 05:59

Message:
Logged In: YES 
user_id=1522083
Originator: YES

File Added: tarfile.patch

----------------------------------------------------------------------

Comment By: Arve Knudsen (arve_knudsen)
Date: 2007-04-06 05:52

Message:
Logged In: YES 
user_id=1522083
Originator: YES

I tested on Ubuntu Linux. Viewing the trunk revision of tarfile.py, I can
see the bug remains. That is, TarFile.__init__ has a default value of None
for the name parameter, but still it passes this parameter directly to
os.path.abspath which does not expect a None value.

----------------------------------------------------------------------

Comment By: Raghuram Devarakonda (draghuram)
Date: 2007-04-05 16:26

Message:
Logged In: YES 
user_id=984087
Originator: NO


When I tested the following code with python 2.5 on linux, I got an
exception:

-------------------
Python 2.5 (r25:51908, Jan 24 2007, 12:48:15) 
[GCC 4.1.0 (SUSE Linux)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import tarfile
>>> f = open("test.tar")
>>> tarfile.open(fileobj=f).getnames()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/local/lib/python2.5/tarfile.py", line 1019, in open
    return func(name, "r", fileobj)
  File "/usr/local/lib/python2.5/tarfile.py", line 1077, in gzopen
    pre, ext = os.path.splitext(name)
  File "/usr/local/lib/python2.5/posixpath.py", line 92, in splitext
    i = p.rfind('.')
AttributeError: 'NoneType' object has no attribute 'rfind'
>>> 
---------------------

However, the test with latest python (built from latest code in svn)
passes.

----------------------
Python 2.6a0 (trunk:54698M, Apr  5 2007, 16:18:31) 
[GCC 4.1.0 (SUSE Linux)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import tarfile
>>> f = open("test.tar")
>>> tarfile.open(fileobj=f).getnames()
['wikipediafs-0.2', 'wikipediafs-0.2/AUTHORS',
'wikipediafs-0.2/ChangeLog', 'wikipediafs-0.2/COPYING',
'wikipediafs-0.2/COPYRIGHT', 'wikipediafs-0.2/VERSION',
'wikipediafs-0.2/README', 'wikipediafs-0.2/setup.py',
'wikipediafs-0.2/site', 'wikipediafs-0.2/site/index.htm',
'wikipediafs-0.2/site/index_fr.htm', 'wikipediafs-0.2/src',
'wikipediafs-0.2/src/wikipediafs',
'wikipediafs-0.2/src/wikipediafs/WikipediaFS.py',
'wikipediafs-0.2/src/wikipediafs/WikipediaArticleList.py',
'wikipediafs-0.2/src/wikipediafs/WikipediaUser.py',
'wikipediafs-0.2/src/wikipediafs/WikipediaArticle.py',
'wikipediafs-0.2/src/wikipediafs/__init__.py',
'wikipediafs-0.2/src/wikipediafs/logger.py',
'wikipediafs-0.2/src/wikipediafs/version.py',
'wikipediafs-0.2/src/mount.wikipediafs', 'wikipediafs-0.2/TODO']
>>
---------------------------

Which platform did you test on? You may want to give the latest version a
try as well. 

Thanks,
Raghu.



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1695229&group_id=5470


More information about the Patches mailing list