Georg Brandl added the comment:
Closing due to lack of feedback.
--
nosy: +georg.brandl
resolution: - invalid
status: pending - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue10040
Changes by Serhiy Storchaka storch...@gmail.com:
--
status: open - pending
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue10040
___
___
Changes by Serhiy Storchaka storch...@gmail.com:
--
nosy: +serhiy.storchaka
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue10040
___
___
Robert Rohde ro...@robertrohde.com added the comment:
It's Windows 7 Ultimate (64-bit) on a very high end system.
I don't think it would be very practical to distribute a 2 GB test file.
Though I might be able to get it to a couple people if someone wanted to really
study the issue.
Though
Antoine Pitrou pit...@free.fr added the comment:
Can you show a snippet of the code (or descrive it in detail) that processes
the GzipFile? Right now it's not obvious which operations you are doing.
--
components: +Library (Lib) -Windows
nosy: +pitrou
stage: unit test needed -
New submission from Robert Rohde ro...@robertrohde.com:
I attempted to use GZipFile to process a 1.93 GB file that expands to 18.8 GB.
This consistently produces the same corrupted output file that has
approximately, but not exactly, the right output file size.
I bypassed GZipFile by calling
Ned Deily n...@acm.org added the comment:
Since you mention 7-zip, does that mean you are seeing the problem on a Windows
platform? If so, exactly which version of Windows and what kind of system?
Also, unless someone recognizes this as a duplicate of an earlier issue, there
may not be much
