This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author ev
Recipients ev
Date 2011-03-14.23:40:31
SpamBayes Score 1.4863555e-11
Marked as misclassified No
Message-id <1300146032.78.0.080952835314.issue11513@psf.upfronthosting.co.za>
In-reply-to
Content
Using Python tip from Sunday, I noticed that tarfile does not elegantly handle ENOENT by raising a single exception:

>>> tarfile.TarFile.gzopen('fdsfd', 'r')
Traceback (most recent call last):
  File "/home/evan/hg/cpython/Lib/tarfile.py", line 1808, in gzopen
    fileobj = gzip.GzipFile(name, mode + "b", compresslevel, fileobj)
  File "/home/evan/hg/cpython/Lib/gzip.py", line 157, in __init__
    fileobj = self.myfileobj = builtins.open(filename, mode or 'rb')
IOError: [Errno 2] No such file or directory: 'fdsfd'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/evan/hg/cpython/Lib/tarfile.py", line 1812, in gzopen
    fileobj.close()
AttributeError: 'NoneType' object has no attribute 'close'

I tried to fix this in a cross-platform way, by attempting to open the file before processing it, and letting the with statement handle calling close:

diff -r 955547e57cff Lib/tarfile.py
--- a/Lib/tarfile.py	Sun Mar 13 19:32:21 2011 +0100
+++ b/Lib/tarfile.py	Mon Mar 14 19:33:21 2011 -0400
@@ -1793,6 +1793,10 @@
         if len(mode) > 1 or mode not in "rw":
             raise ValueError("mode must be 'r' or 'w'")
 
+        if mode == "r":
+            # force an exception if the file does not exist.
+            with open(name):
+                pass
         try:
             import gzip
             gzip.GzipFile

However, this produces infinite recursion:
...
  File "/home/evan/hg/cpython/Lib/tarfile.py", line 1738, in open
    return func(name, "r", fileobj, **kwargs)
  File "/home/evan/hg/cpython/Lib/tarfile.py", line 1798, in gzopen
    with open(name):
  File "/home/evan/hg/cpython/Lib/tarfile.py", line 1738, in open
    return func(name, "r", fileobj, **kwargs)
RuntimeError: maximum recursion depth exceeded

Curiously, if I force the ValueError in that same function to be triggered (by passing a three character string for the mode), that exception is raised fine.  I am therefore wondering if this is a bug in the exit processing.

Unfortunately, my attempts at producing a general test case have been unsuccessful thusfar.
History
Date User Action Args
2011-03-14 23:40:32evsetrecipients: + ev
2011-03-14 23:40:32evsetmessageid: <1300146032.78.0.080952835314.issue11513@psf.upfronthosting.co.za>
2011-03-14 23:40:32evlinkissue11513 messages
2011-03-14 23:40:32evcreate