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.

classification
Title: mmap tries to truncate special files
Type: Stage:
Components: Library (Lib) Versions:
process
Status: closed Resolution: rejected
Dependencies: Superseder:
Assigned To: Nosy List: aerojockey, josiahcarlson, nnorwitz, tim.peters
Priority: normal Keywords:

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) * (Python committer) 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) * (Python committer) 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) * (Python committer) 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) * (Python triager) 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:17adminsetgithub: 43310
2006-05-02 20:56:38aerojockeycreate