Bugs item #1480678, was opened at 2006-05-02 13:56 Message generated for change (Comment added) made by josiahcarlson You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1480678&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: Not a Bug Status: Closed Resolution: Rejected Priority: 5 Submitted By: Carl Banks (aerojockey) Assigned to: Nobody/Anonymous (nobody) Summary: mmap tries to truncate special files Initial Comment: One Unix, the resize() method of an mmap object calls ftruncate to also resize the associated file. Problem is, ftruncate fails if the fd refers to a special file. This is a problem for someone trying to resize an anonymous memory map using /dev/zero. Apparently hasn't been fixed in 2.5 (based on SVN and changelogs) but I haven't tested it. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2006-05-06 12:29 Message: Logged In: YES user_id=341410 The user could also os.tempnam() to come up with a file name, create a 0-lengthed file, mmap it, unlink it, then resize. This method will create an anonymous mmap that is resizable (according to the docs). ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2006-05-03 12:02 Message: Logged In: YES user_id=31435 I have to confess I don't know _why_ resize() changes the size of the file too, and think that's a debatable design decision. But when code is working as intended and as documented, by definition that's not "a bug". The reason "it worked" in Python 2.3 is explained in bug 728515: http://www.python.org/sf/728515 As it says there, it was a bug that resize() resized the file on Windows, but neglected to do so on Unixish boxes at the time. That bug was fixed by making it resize the file on Unixish boxes too. Since the intent here is clear (albeit questionable) and documented, I'm closing this as not-a-bug. ---------------------------------------------------------------------- Comment By: Carl Banks (aerojockey) Date: 2006-05-03 11:19 Message: Logged In: YES user_id=1515186 Well, since resizing an anonymous array seems a reasonable thing to do, and because it worked in Python 2.3, I presumed that the error was an oversight, and not intended behavior. If it is, in fact, intended behavior, then ok, though I don't agree with it. (It's not as if /dev/zero has fixed size that doesn't change; it's inherently sizeless.) ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2006-05-02 23:13 Message: Logged In: YES user_id=31435 Ya, this isn't a bug: resize() is documented as changing the size of _both_ the map and the file. If the size of the file can't be changed, then of course resize() will fail. aerojockey: can't you simply close your current map and create a new map with the size you want? ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-05-02 22:21 Message: Logged In: YES user_id=33168 I don't understand what the problem is. ISTM if you resize a special file an exception will be raised. Is that not the case? What do you expect to happen? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1480678&group_id=5470 _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
