Message128274
| Author |
wrobell |
| Recipients |
eckhardt, jbeezley, loewis, nadeem.vawda, pitrou, rosslagerwall, saa, vstinner, wrobell |
| Date |
2011年02月10日.09:43:31 |
| SpamBayes Score |
3.1989988e-10 |
| Marked as misclassified |
No |
| Message-id |
<1297331012.21.0.825033495967.issue4681@psf.upfronthosting.co.za> |
| In-reply-to |
| Content |
> > will this patch support off_t for "mmap.resize" as well?
> > ftruncate uses off_t for the length of a file as well.
> No, it doesn't because resize() resizes the amount mmapped in memory
> which can't be more than ssize_t anyway. However, resizing does work on
> a 12GiB file with a large offset, e.g. 6GiB.
i am bit lost. ftruncate is used to enlarge the file, isn't it?
please consider the script:
-- rr.py ---
import mmap
f = open('test.x', 'w+b')
f.write(b'\x00' * 10)
f.flush()
fm = mmap.mmap(f.fileno(), 0)
fm.resize(5 * 1024 ** 3)
fm.close()
f.close()
------------
the script above resizes file from 10 bytes
to 5 * 1024 ** 3 bytes with mmap.resize (but
not 5 * 1024 ** 3 + 10!)
now, on 32-bit linux (with off_t):
$ python3 rr.py
Traceback (most recent call last):
File "rr.py", line 8, in <module>
fm.resize(5 * 1024 ** 3)
OverflowError: Python int too large to convert to C ssize_t
above script works perfectly on 64-bit version of linux
with just 4GB of RAM.
maybe i do not understand some magic here, but clearly one
can mmap.resize to a file size much beyond the amount of memory. |
|