[ python-Bugs-1223238 ] race in os.makedirs()

[SourceForge.net]

Bugs item #1223238, was opened at 2005-06-18 18:37
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=1223238&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: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Mattias Engdegård (yorick)
Assigned to: Nobody/Anonymous (nobody)
Summary: race in os.makedirs()

Initial Comment:
os.makedirs() can fail if one of its components is
created while it is running (perhaps by another
process). This is because it checks for each directory
if it exists before creating it.

This is bad programming style. A correct implementation
would just call mkdir() on each directory (starting
with the rightmost, probably) and ignoring any EEXIST
error. This would not only fix the bug, it would also
be faster (fewer syscalls).

The patch is simple, but there is a wart in the design:
os.makedirs() throws an error if the (rightmost)
directory already exists, although by calling this
function the user has clearly indicated that she wants
the directories to be created if they don't exist and
have no complaints otherwise.

This leads to code like:

try:
os.makedirs(path)
except OSError:
pass

which is doubly bad because it hides the race condition!

So, before I submit a patch, should we:
a) just fix this bug but keep the old design
b) fix this bug, and don't throw an error if the dir exists

or maybe do a) for the next 2.4.x bugfix release and b)
in 2.5?


--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1223238&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-1221424 ] buffer() object broken.

[SourceForge.net]

Bugs item #1221424, was opened at 2005-06-15 18:17
Message generated for change (Comment added) made by nascheme
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1221424&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 Interpreter Core
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Ray Schumacher (rjs_org)
Assigned to: Neil Schemenauer (nascheme)
Summary: buffer() object broken.

Initial Comment:
Same as:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1033720&group_id=5470:

Still broken in 2.4.1...!

C:\projects\temp\fftw>python
ActivePython 2.4.1 Build 245 (ActiveState Corp.) based on
Python 2.4.1 (#65, Mar 30 2005, 09:33:37) [MSC v.1310
32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for
more information.
>>> import Numeric
>>> i = Numeric.zeros(8)
>>> repr(buffer(i))
''
>>> repr(buffer(""))
''

(Numeric v23.8)

--

>Comment By: Neil Schemenauer (nascheme)
Date: 2005-06-18 17:26

Message:
Logged In: YES 
user_id=35752

Calling PyObject_AsReadBuffer() is the proper way to get the
address.  It should work with older versions of Python as
well.  The buffer() object was changed in 2.4 to no longer
keep a pointer to buffer memory, only the underlying
PyObject.  It would be possible to make the repr look the
same as pre-2.4 Python.  Do you still care?

--

Comment By: Ray Schumacher (rjs_org)
Date: 2005-06-17 19:04

Message:
Logged In: YES 
user_id=287034

In 2.3, the actual adress of the first element of an array
could be parsed for doing a memmove(), and now, not, which
breaks some older code. If this is a "more Pythonic"
feature, then OK; the previous resolution said "Fixed in
bufferobject.c 2.25." without remark. I assumed that it had
been restored to the previous.
I now have:
ptr = tpcnv[a.typecode()]()
pythonapi.PyObject_AsReadBuffer(py_object(a), 
   
byref(ptr), 
   
byref(c_int()))
ptr.refed_array = a
instead of:
split(repr(buffer(a)))[5][:-1]
to get/use an address with ctypes...

--

Comment By: Neil Schemenauer (nascheme)
Date: 2005-06-17 17:52

Message:
Logged In: YES 
user_id=35752

The repr of a buffer() object has indeed changed.  I don't
see how that's a bug though.

--

Comment By: Ray Schumacher (rjs_org)
Date: 2005-06-17 17:31

Message:
Logged In: YES 
user_id=287034

repr(buffer("")) used to return:


now returns:
>>> repr(buffer(""))
''

same as:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1033720&group_id=5470


--

Comment By: Neil Schemenauer (nascheme)
Date: 2005-06-16 18:49

Message:
Logged In: YES 
user_id=35752

Please explain exactly what you think is broken about the
buffer object.

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1221424&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-1220756 ] Re-importing embedded thread dumps core

[SourceForge.net]

Bugs item #1220756, was opened at 2005-06-14 21:16
Message generated for change (Comment added) made by nascheme
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1220756&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: Threads
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Jay T Miller (jaytmiller)
Assigned to: Neil Schemenauer (nascheme)
Summary: Re-importing embedded thread dumps core

Initial Comment:
I noticed the following while working on an "embedding
numarray" problem:

[EMAIL PROTECTED] Python-2.4.1]$
Python-2.4.1/Demo/embed/loop 'from thread import *' 10
[6675 refs]
[7009 refs]
[7320 refs]
[7631 refs]
[7942 refs]
[8253 refs]
loop: Objects/typeobject.c:2104: type_dealloc:
Assertion `type->tp_flags & (1L<<9)' failed.
Abort (core dumped)

The tp_flags bit in question is:

#define Py_TPFLAGS_HEAPTYPE (1L<<9)



--

>Comment By: Neil Schemenauer (nascheme)
Date: 2005-06-18 17:41

Message:
Logged In: YES 
user_id=35752

I add an incref in gcmodule.c 2.81.  "./loop 'import gc'" no
longer crashes but it does leak memory. :-(

--

Comment By: Michael Hudson (mwh)
Date: 2005-06-15 12:28

Message:
Logged In: YES 
user_id=6656

Fixed the issue in the report in revision 2.62 of Modules/threadmodule.c.

I'm leaving this open because "./loop 'import gc'" crashes and because I 
think there are too many places that incref before 
PyModule_AddObject()...

Neil, any ideas about the gc one? 

--

Comment By: Michael Hudson (mwh)
Date: 2005-06-15 11:35

Message:
Logged In: YES 
user_id=6656

Oh dear.  The problem here is that PyModule_AddObject steals a 
reference to the object, but this is not taken care of in threadmodule.c (or 
gcmodule, it turns out, and I bet many other places).

Shouldn't be too hard to fix.

(Looks like noone's run Demo/embed/loop for a while...)

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1220756&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-1223238 ] race in os.makedirs()

[SourceForge.net]

Bugs item #1223238, was opened at 2005-06-18 16:37
Message generated for change (Comment added) made by nascheme
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1223238&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: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Mattias Engdegård (yorick)
Assigned to: Nobody/Anonymous (nobody)
Summary: race in os.makedirs()

Initial Comment:
os.makedirs() can fail if one of its components is
created while it is running (perhaps by another
process). This is because it checks for each directory
if it exists before creating it.

This is bad programming style. A correct implementation
would just call mkdir() on each directory (starting
with the rightmost, probably) and ignoring any EEXIST
error. This would not only fix the bug, it would also
be faster (fewer syscalls).

The patch is simple, but there is a wart in the design:
os.makedirs() throws an error if the (rightmost)
directory already exists, although by calling this
function the user has clearly indicated that she wants
the directories to be created if they don't exist and
have no complaints otherwise.

This leads to code like:

try:
os.makedirs(path)
except OSError:
pass

which is doubly bad because it hides the race condition!

So, before I submit a patch, should we:
a) just fix this bug but keep the old design
b) fix this bug, and don't throw an error if the dir exists

or maybe do a) for the next 2.4.x bugfix release and b)
in 2.5?


--

>Comment By: Neil Schemenauer (nascheme)
Date: 2005-06-18 17:43

Message:
Logged In: YES 
user_id=35752

I vote to fix the design for 2.5.  Backporting the minimal
fix to 2.4 would be optional, IMO.

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1223238&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-1222928 ] it's -> its

[SourceForge.net]

Bugs item #1222928, was opened at 2005-06-17 21:57
Message generated for change (Settings changed) made by nascheme
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1222928&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: Python 2.3
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Ed Swierk (eswierk)
>Assigned to: Neil Schemenauer (nascheme)
Summary: it's -> its

Initial Comment:
These are not earth-shattering bugs, but for the sake
of my obsessiveness... "it's" should be changed to
"its" in each of these instances:

ref/id-classes.html:  and it's implementation
(including the standard library);

mac/module-FrameWork.html:that shouldn't be difficult),
that it's dialog support is minimal and

mac/module-FrameWork.html:that it's control/toolbar
support is non-existent.

api/common-structs.html:  that it's own expansion
varies depending on the definition of

api/instanceObjects.html:  Create a new instance of a
specific class without calling it's

doc/inline-markup.html:  be used for simple
constant definitions.  Examples of it's use

doc/info-units.html:  be used for simple constant
definitions.  Examples of it's use

lib/module-cgitb.html:scripts.  (It's name is a bit
misleading.  It was originally designed to


--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1222928&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-1195576 ] [AST] Patch [ 1190012 ] should've checked for SyntaxWarnings

[SourceForge.net]

Bugs item #1195576, was opened at 2005-05-04 23:13
Message generated for change (Comment added) made by nascheme
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1195576&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: Parser/Compiler
Group: AST
Status: Open
Resolution: None
Priority: 5
Submitted By: logistix (logistix)
Assigned to: Brett Cannon (bcannon)
Summary: [AST] Patch [ 1190012 ] should've checked for SyntaxWarnings

Initial Comment:
"[ 1190012 ] don't assume all errors are syntax errors"
should also check allow SyntaxWarnings to pass.  This
is a one-line fix at around line 104 in
ast_error_finish in ast.c.

This causes the failure in test_warnings.py.

Brett,

If you really want a patch, I can get you one, but
right now my copy of ast.c is a little too far out of
sync to generate a clean patch.  The fix is pretty
trivial though.

Let me know.

-Grant



--

>Comment By: Neil Schemenauer (nascheme)
Date: 2005-06-18 18:05

Message:
Logged In: YES 
user_id=35752

I haven't dug to deep into this but test_warnings now
passes.  The ast.c ast_error_finish function doesn't seem to
have been changed.  I think test_warnings was failing for
some other reason.

It looks like SyntaxWarnings are not currently generated by
newcompile.c.  I'm leaving this issue open until that gets
fixed.  Probably a test should be added that actually causes
a SyntaxWarning to be generated by the compiler.

--

Comment By: Brett Cannon (bcannon)
Date: 2005-05-06 20:01

Message:
Logged In: YES 
user_id=357491

I shouldn't need a patch, but it might be a little while
until I get to this.  I am down to the last couple of weeks
of the quarter and I am racing to get my masters thesis done
before I graduate.  Plus a quick recompile the other night
under gcc 4 led to a ton of errors for me (hoping it was
just a fluke; something about sem_init() ).

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1195576&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-1209560 ] spurious blank page in dist.pdf

[SourceForge.net]

Bugs item #1209560, was opened at 2005-05-27 02:33
Message generated for change (Comment added) made by birkenfeld
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1209560&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: Closed
>Resolution: Fixed
Priority: 5
Submitted By: paul rubin (phr)
Assigned to: Reinhold Birkenfeld (birkenfeld)
Summary: spurious blank page in dist.pdf

Initial Comment:
In the US Letter sized version of dist.pdf in the
current download zip (Python 2.4.1), the third page of
the file (the one immediately preceding the table of
contents, which starts with roman numeral "i") is
blank.  That means that page "i" of the table of
contents, and page "1" of the actual document, begin on
even-numbered pages in the file.  This is bad because
if you print on a duplex printer, page 1 comes out on
the back of page ii, page 3 comes out on the back of
page 2, etc.  You want odd numbered pages to be on the
front and even numbered pages to be on the back, so
page 2 should be on the back of page 1, etc.

This is probably a problem with the latex extension
that made the pdf file and so it probably affects the
other pdfs as well as dist.pdf, but that's the only one
I printed.

--

>Comment By: Reinhold Birkenfeld (birkenfeld)
Date: 2005-06-18 22:12

Message:
Logged In: YES 
user_id=1188172

Thanks for the report! 
Checked in as Doc/dist/dist.tex rev 1.95, 1.86.2.5.

--

Comment By: Reinhold Birkenfeld (birkenfeld)
Date: 2005-06-04 13:12

Message:
Logged In: YES 
user_id=1188172

This indeed happens only in dist.pdf. Attaching a patch
which includes the copyright, as in all other documents, and
magically, the paging is right.

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1209560&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-1219273 ] 'Expression' AST Node not documented

[SourceForge.net]

Bugs item #1219273, was opened at 2005-06-12 20:27
Message generated for change (Comment added) made by birkenfeld
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1219273&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
Submitted By: Martin Miller (mrmiller)
Assigned to: Nobody/Anonymous (nobody)
Summary: 'Expression' AST Node not documented

Initial Comment:
Python 2.4.1 documentation
===
The table at the end of section "19.3.1 AST Nodes" 
does not list Node type 'Expression' and its associated
information.

Also, the BNF for 'expression' shown in the file


> expression ::= 
>  or_test | lambda_form

can't be correct because it doesn't cover cases of a
simple literals (or identifiers) such as 42 and simple
binary operator expressions such as 1+2.


--

>Comment By: Reinhold Birkenfeld (birkenfeld)
Date: 2005-06-18 22:34

Message:
Logged In: YES 
user_id=1188172

To your second comment: the BNF for expression is correct
since or_test can contain and_test which can contain
not_test and so on until primary, atom, literal.

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1219273&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-1115886 ] os.path.splitext don't handle unix hidden file correctly

[SourceForge.net]

Bugs item #1115886, was opened at 2005-02-04 02:27
Message generated for change (Comment added) made by birkenfeld
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1115886&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.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Jeong-Min Lee (falsetru)
Assigned to: Nobody/Anonymous (nobody)
Summary: os.path.splitext don't handle unix hidden file correctly

Initial Comment:
I expected this.
>>> os.path.splitext('/path/to/.Hiddenfile')
('/path/to/.Hiddenfile', '')

but got this.
>>> os.path.splitext('/path/to/.Hiddenfile')
('/path/to/', '.Hiddenfile')



--

>Comment By: Reinhold Birkenfeld (birkenfeld)
Date: 2005-06-18 23:05

Message:
Logged In: YES 
user_id=1188172

Interestingly, altering the behaviour of splitext in such a
way does not contradict the documentation, which is:

"""
Split the pathname path into a pair (root, ext) such that
root + ext == path, and ext is empty or begins with a period
and contains at most one period.
"""

Personally I'm in favour of this change (on Unix it makes
sense, while on Windows you can hardly find an
"extension-only" file).

--

Comment By: engelbert gruber (grubert)
Date: 2005-06-13 16:12

Message:
Logged In: YES 
user_id=147070

from test_posixpath.py ::

  self.assertEqual(posixpath.splitext(".ext"), ("", ".ext"))
  
IMHO should then return (".ext",""). if this is desired ::

  if i<=p.rfind('/'):   

  return p, ''  

  else: 
   
  return p[:i], p[i:]   
   

should do


--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1115886&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-1215928 ] Large tarfiles cause overflow

[SourceForge.net]

Bugs item #1215928, was opened at 2005-06-06 21:19
Message generated for change (Comment added) made by birkenfeld
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1215928&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.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Tom Emerson (tree)
Assigned to: Reinhold Birkenfeld (birkenfeld)
Summary: Large tarfiles cause overflow

Initial Comment:
I have a 4 gigabyte bz2 compressed tarfile containing some 3.3 
million documents. I have a script which opens this file with "r:bz2" 
and is simply iterating over the contents using next(). With 2.4.1 I 
still get an Overflow error (originally tried with 2.3.5 as packaged in 
Mac OS 10.4.1):

Traceback (most recent call last):
  File "extract_part.py", line 47, in ?
main(sys.argv)
  File "extract_part.py", line 39, in main
pathnames = find_valid_paths(argv[1], 1024, count)
  File "extract_part.py", line 13, in find_valid_paths
f = tf.next()
  File "/usr/local/lib/python2.4/tarfile.py", line 1584, in next
self.fileobj.seek(self.offset)
OverflowError: long int too large to convert to int


--

>Comment By: Reinhold Birkenfeld (birkenfeld)
Date: 2005-06-18 23:26

Message:
Logged In: YES 
user_id=1188172

I looked into this a bit further, and noticed the following:

The modules bz2, cStringIO and mmap all use plain integers
to represent file offsets given to or returned by seek(),
tell() and truncate().

They should be corrected to use a 64-bit type when having
large file support. fileobject.c defines an own type for
that, Py_off_t, which should be shared among the other modules.

Conditional compile is needed since different
macros/functions must be used.

--

Comment By: Raymond Hettinger (rhettinger)
Date: 2005-06-13 03:32

Message:
Logged In: YES 
user_id=80475

Is there a way to write a test for this?
Can it be done without a conditional compile?
Is the problem one that occurs in other code outside of bz?

--

Comment By: Reinhold Birkenfeld (birkenfeld)
Date: 2005-06-10 13:45

Message:
Logged In: YES 
user_id=1188172

Attaching corrected patch.

--

Comment By: Reinhold Birkenfeld (birkenfeld)
Date: 2005-06-09 22:31

Message:
Logged In: YES 
user_id=1188172

Attaching a patch which mimics the behaviour of normal file
objects. This should resolve the issue on platforms with
large file support.

--

Comment By: Lars Gustäbel (gustaebel)
Date: 2005-06-07 15:23

Message:
Logged In: YES 
user_id=642936

A quick look at the problem reveals that this is a bug in
bz2.BZ2File. The seek() method does not allow position
values >= 2GiB.

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1215928&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-1215928 ] Large tarfiles cause overflow

[SourceForge.net]

Bugs item #1215928, was opened at 2005-06-06 14:19
Message generated for change (Comment added) made by rhettinger
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1215928&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.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Tom Emerson (tree)
>Assigned to: Martin v. Löwis (loewis)
Summary: Large tarfiles cause overflow

Initial Comment:
I have a 4 gigabyte bz2 compressed tarfile containing some 3.3 
million documents. I have a script which opens this file with "r:bz2" 
and is simply iterating over the contents using next(). With 2.4.1 I 
still get an Overflow error (originally tried with 2.3.5 as packaged in 
Mac OS 10.4.1):

Traceback (most recent call last):
  File "extract_part.py", line 47, in ?
main(sys.argv)
  File "extract_part.py", line 39, in main
pathnames = find_valid_paths(argv[1], 1024, count)
  File "extract_part.py", line 13, in find_valid_paths
f = tf.next()
  File "/usr/local/lib/python2.4/tarfile.py", line 1584, in next
self.fileobj.seek(self.offset)
OverflowError: long int too large to convert to int


--

>Comment By: Raymond Hettinger (rhettinger)
Date: 2005-06-18 17:05

Message:
Logged In: YES 
user_id=80475

Martin, please look at this when you get a chance.

--

Comment By: Reinhold Birkenfeld (birkenfeld)
Date: 2005-06-18 16:26

Message:
Logged In: YES 
user_id=1188172

I looked into this a bit further, and noticed the following:

The modules bz2, cStringIO and mmap all use plain integers
to represent file offsets given to or returned by seek(),
tell() and truncate().

They should be corrected to use a 64-bit type when having
large file support. fileobject.c defines an own type for
that, Py_off_t, which should be shared among the other modules.

Conditional compile is needed since different
macros/functions must be used.

--

Comment By: Raymond Hettinger (rhettinger)
Date: 2005-06-12 20:32

Message:
Logged In: YES 
user_id=80475

Is there a way to write a test for this?
Can it be done without a conditional compile?
Is the problem one that occurs in other code outside of bz?

--

Comment By: Reinhold Birkenfeld (birkenfeld)
Date: 2005-06-10 06:45

Message:
Logged In: YES 
user_id=1188172

Attaching corrected patch.

--

Comment By: Reinhold Birkenfeld (birkenfeld)
Date: 2005-06-09 15:31

Message:
Logged In: YES 
user_id=1188172

Attaching a patch which mimics the behaviour of normal file
objects. This should resolve the issue on platforms with
large file support.

--

Comment By: Lars Gustäbel (gustaebel)
Date: 2005-06-07 08:23

Message:
Logged In: YES 
user_id=642936

A quick look at the problem reveals that this is a bug in
bz2.BZ2File. The seek() method does not allow position
values >= 2GiB.

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1215928&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com