I can easily enough change the Windows file.truncate() to leave the file
position alone, although it will *have* to move it if the initial position
is beyond the truncated size. I'm baffled by what
http://www.opengroup.org/onlinepubs/7908799/xsh/ftruncate.html
intends by
These functions do not modify the file offset for any open file
descriptions associated with the file
in the cases where the current file position is indeed beyond the truncated
size. A Unix geek will have to answer that.
That leaves the question of whether our docs are saying something intended
when they say:
If the optional size argument present, the file is truncated
to (at most) that size.
Do you read that as saying file.truncate() may *increase* the size of the
file? I didn't at first, but on twelfth thought I'm not sure what it's
trying to say. Perhaps it's just saying the new size will be <= the
specified size, and that "==" may or may not obtain.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4