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.

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.

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.

File Added: tarfile.patch

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

Can we expect a fixed 2.5 release soon?

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.

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.

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.

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? 

Lars: AFAICT this is a regression in 2.5, since my code worked without problems with 2.4. Also, how can it be a feature that TarFile.__init__ doesn't support its own default value for the 'name' parameter?

Thank you for making clear that this is a regression. This is a completely different thing and makes the previous discussion obsolete...
Unfortunately, this will not go into 2.5.1, we're too late. But I will come up with a reasonable fix and testcases for 2.5.2.

File Added: tarfile.patch

File Added: tarfile.patch

I checked in a fix in the release25-maint branch (rev. 54889), so it will show up in the 2.5.2 release.

So this can be closed?