[ python-Bugs-1496501 ] tarfile.py: dict order dependency

[SourceForge.net]

Bugs item #1496501, was opened at 2006-05-28 20:42
Message generated for change (Comment added) made by gustaebel
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1496501&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: Python Library
Group: Python 2.5
>Status: Closed
>Resolution: Accepted
Priority: 5
Private: No
Submitted By: Armin Rigo (arigo)
Assigned to: Lars Gustäbel (gustaebel)
Summary: tarfile.py: dict order dependency

Initial Comment:
When guessing the type of a file, tarfile.py tries to
open it in .tar, .tar.gz and .tar.bz2 modes
successfully.  The problem is that in conjunction with a
fileobj argument, failed attempts can advance the
current position of the fileobj, and cause the following
attempts to fail as well.

This didn't show up so far because, by chance, the order
in which the OPEN_METH dictionary is enumerated is
somehow the "correct" one.  The problem can be seen by
changing this order and re-running test_tarfile.py; for
example, reverse the order (tarfile.py line 1013):

    for comptype in reversed(cls.OPEN_METH):


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

>Comment By: Lars Gustäbel (gustaebel)
Date: 2006-12-27 11:39

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

Fixed with said patch.

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

Comment By: Jack Diederich (jackdied)
Date: 2006-06-10 19:46

Message:
Logged In: YES 
user_id=591932

added patch 1504073 because SF won't let just anyone attach
files to bugs.

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

Comment By: Jack Diederich (jackdied)
Date: 2006-06-10 18:15

Message:
Logged In: YES 
user_id=591932

The invidual openers could tell() the fileobj and revert
with a seek() on failure.  The module requires those methods
be implemented already to work so that is safe.  I'll cook
up a patch.

But basically open() isn't as extensible as it seems. 
Stream reading and writing isn't supported for injected
compression types and appending only works on plain tarfiles.

I'm guessing that isn't a problem in practice or someone
would have mentioned it by now ;)


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

Comment By: Armin Rigo (arigo)
Date: 2006-06-10 12:46

Message:
Logged In: YES 
user_id=4771

If possible, I would prefer that the constructors were fixed
to become order-independent.  Not sure how easy this is,
though.

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

Comment By: Jack Diederich (jackdied)
Date: 2006-06-09 21:56

Message:
Logged In: YES 
user_id=591932

I took a look at tarfile.py and though there is this comment
about OPEN_METH

# This concept allows one to subclass TarFile without losing
the comfort of
# the super-constructor. A sub-constructor is registered and
made available
# by adding it to the mapping in OPEN_METH.

because adding items to OPEN_METH could change the order and
break the Tarfile.open() classmethod I doubt adding to
OPEN_METH is done in practice.

+1 for renaming OPEN_METH to _OPEN_METH and making it a list
of two-tuples.

+0 on changing the two tups from ('typename', 'funcname') to
('typename', function_ref) and dropping the getattr
functionality.  The three default openers are not listed in
the public interface so if anyone is subclassing Tarfile and
overriding them (doubtful) they are doing so at their own peril.

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

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