This would be ok if the underlying operating system flushed the disk cache upon close(), but I'm afraid this is not the case (at least on linux). This is from man 2 close:
A successful close does not guarantee that the data has been success- fully saved to disk, as the kernel defers writes. It is not common for a filesystem to flush the buffers when the stream is closed. If you need to be sure that the data is physically stored use fsync(2). (It will depend on the disk hardware at this point.)
From sendmail/README from sendmail 8.12.10.Beta2:
REQUIRES_DIR_FSYNC Turn on support for file systems that require to
call fsync() for a directory if the meta-data in it has
been changed. This should be turned on at least for older
versions of ReiserFS; it is enabled by default for Linux.
According to some information this flag is not needed
anymore for kernel 2.4.16 and newer. We would appreciate
feedback about the semantics of the various file systems
available for Linux.
An alternative to this compile time flag is to mount the
queue directory without the -async option, or using
chattr +S on Linux.So, theoretically, for some filesystems on some versions of Linux (with more modern kernels), this should work as expected.
Still, the code should be made more robust to deal with this issue.
-- Brad Knowles, <[EMAIL PROTECTED]>
"They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety."
-Benjamin Franklin, Historical Review of Pennsylvania.GCS/IT d+(-) s:+(++)>: a C++(+++)$ UMBSHI++++$ P+>++ L+ !E-(---) W+++(--) N+ !w--- O- M++ V PS++(+++) PE- Y+(++) PGP>+++ t+(+++) 5++(+++) X++(+++) R+(+++) tv+(+++) b+(++++) DI+(++++) D+(++) G+(++++) e++>++++ h--- r---(+++)* z(+++)
_______________________________________________ Mailman-Developers mailing list [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/mailman-developers
