[ python-Bugs-1496501 ] tarfile.py: dict order dependency
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
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1622896 ] Exception when compressing certain data with bz2
Bugs item #1622896, was opened at 2006-12-27 15:26
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1622896&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: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Alex Gontmakher (gsasha)
Assigned to: Nobody/Anonymous (nobody)
Summary: Exception when compressing certain data with bz2
Initial Comment:
Looks like an out-of-bounds array access... might be a security problem.
The attached file includes a script which, when executed, tries to pack the two
given directories with a bz2 compressor. On my machine (stock 32 bit Ubuntu
Edgy), the program fails with the following exception:
Traceback (most recent call last):
File "test.py", line 13, in ?
block = compressor.compress(open("compress-0067/"+file, "rb").read())
ValueError: the bz2 library has received wrong parameters
The problem occurs under either python2.4 or 2.5 (I don't have other versions
to test with).
Sorry, the file is large... I tried to reduce the example to smaller number of
files etc., but no such luck. The file is too large to be submitted here as an
attachment, so I have uploaded it to
http://www.cs.technion.ac.il/~gsasha/testcase.tar.bz2
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1622896&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1568240 ] Tix is not included in 2.5 for Windows
Bugs item #1568240, was opened at 2006-09-30 12:19 Message generated for change (Comment added) made by tzot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1568240&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: Build Group: Python 2.5 Status: Open Resolution: None Priority: 7 Private: No Submitted By: Christos Georgiou (tzot) Assigned to: Martin v. Löwis (loewis) Summary: Tix is not included in 2.5 for Windows Initial Comment: (I hope "Build" is more precise than "Extension Modules" and "Tkinter" for this specific bug.) At least the following files are missing from 2.5 for Windows: DLLs\tix8184.dll tcl\tix8184.lib tcl\tix8.1\* -- >Comment By: Christos Georgiou (tzot) Date: 2006-12-27 19:46 Message: Logged In: YES user_id=539787 Originator: YES Should we bump the bug up and/or assign it to Neal Norwitz as he requested on Python-Dev? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1568240&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1623153 ] preferred diff format should be mentioned as "unified".
Bugs item #1623153, was opened at 2006-12-27 16:18 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1623153&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: Documentation Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Raghuram Devarakonda (draghuram) Assigned to: Nobody/Anonymous (nobody) Summary: preferred diff format should be mentioned as "unified". Initial Comment: The page at http://www.python.org/dev/tools/ mentions that context diffs are preferred. However, the link at http://www.python.org/dev/patches/ mentions that "We like unified diffs. We grudgingly accept contextual diffs.". So "tools" page should preferably mention unified diffs as well. Thanks, Raghu -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1623153&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1545837 ] array.array borks on deepcopy
Bugs item #1545837, was opened at 2006-08-24 02:49
Message generated for change (Comment added) made by nnorwitz
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1545837&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: Open
>Resolution: Accepted
>Priority: 9
Private: No
Submitted By: Václav Haisman (wilx)
Assigned to: Neal Norwitz (nnorwitz)
Summary: array.array borks on deepcopy
Initial Comment:
Hi,
I think there is a bug arraymodule.c this line:
{"__deepcopy__",(PyCFunction)array_copy,METH_NOARGS,
copy_doc},
should probably have METH_O instead of METH_NOARGS
there, since according to docs and the prototype of the
array_copy() function there is one parameter.
--
>Comment By: Neal Norwitz (nnorwitz)
Date: 2006-12-27 23:59
Message:
Logged In: YES
user_id=33168
Originator: NO
Thomas, was there any reason this wasn't checked in to 2.5? I'm guessing
it was just forgotten. I don't see any mention in Misc/NEWS either.
--
Comment By: Thomas Wouters (twouters)
Date: 2006-08-29 00:35
Message:
Logged In: YES
user_id=34209
Not unless you want another release candidate. copy.deepcopy
has never worked on array instances, so it's not a
release-preventing bug (but each bugfix may *add* a
release-preventing bug by accident :)
--
Comment By: Raymond Hettinger (rhettinger)
Date: 2006-08-28 06:32
Message:
Logged In: YES
user_id=80475
Should this be fixed in the release candidate?
--
Comment By: Thomas Wouters (twouters)
Date: 2006-08-24 11:50
Message:
Logged In: YES
user_id=34209
Thanks! Fixed in the trunk (which is 2.6-to-be) revision
51565, and it will also be fixed for Python 2.4.4 and 2.5.1.
It's unfortunately just a bit too late for 2.5.0.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1545837&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
