Issue1480678
This issue tracker has been migrated to GitHub,
and is currently read-only.
For more information,
see the GitHub FAQs in the Python's Developer Guide.
Created on 2006-05-02 20:56 by aerojockey, last changed 2022-04-11 14:56 by admin. This issue is now closed.
Messages (6) | |||
---|---|---|---|
msg28402 - (view) | Author: Carl Banks (aerojockey) | Date: 2006-05-02 20:56 | |
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. |
|||
msg28403 - (view) | Author: Neal Norwitz (nnorwitz) * | Date: 2006-05-03 05:21 | |
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? |
|||
msg28404 - (view) | Author: Tim Peters (tim.peters) * | Date: 2006-05-03 06:13 | |
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? |
|||
msg28405 - (view) | Author: Carl Banks (aerojockey) | Date: 2006-05-03 18:19 | |
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.) |
|||
msg28406 - (view) | Author: Tim Peters (tim.peters) * | Date: 2006-05-03 19:02 | |
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. |
|||
msg28407 - (view) | Author: Josiah Carlson (josiahcarlson) * | Date: 2006-05-06 19:29 | |
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). |
History | |||
---|---|---|---|
Date | User | Action | Args |
2022-04-11 14:56:17 | admin | set | github: 43310 |
2006-05-02 20:56:38 | aerojockey | create |