Our experiments suggest that ext2, ext3,
and reiserfs optimize for sparse files so there is no such guarantee.
AFAICT from some quick googling and wikipediaing, the same is true
for NTFS, XFS, JFS, ZFS. I suspect we've accounted for the majority
of the production Zope installations in the world.
In that case it would seem better to just remove the ineffectual
-0. See my other response. +1 on beefing up the comment, though. On
all systems the code does no harm and does /inform/ the OS of how
large a file is needed. At least on NTFS it also does all that
reasonably can be done to ensure enough space actually exists (while
NTFS supports sparse files, it's not the default, and the ZEO code
does not create a sparse file under NTFS).
The Windows behavior could be effectively gotten on most other
platforms by adding a loop to write a non-NUL byte to every (say)
512th byte position. This would be redundant on Windows (NTFS
physically writes NUL bytes to every "missing" position in a dense
file whenever the EOF pointer advances), but would do no harm there
Or it could be that people are happy to have ZEO blow up later ;-)
For more information about ZODB, see the ZODB Wiki:
ZODB-Dev mailing list - ZODB-Dev@zope.org