wietse@porcupine.org (Wietse Venema) writes: > open() implements O_CREAT|O_EXCL correctly. > > fsync(fd) guarantees no loss of file content or pathname information. > close() after fsync() is not allowed to break this guarantee. > > rename() and link() are synchronous. Some applications also demand > that the operations be atomic. > > rename() is safe: it never loses pathname information no matter > when the operation is interrupted, and no matter why it fails. > > An operation that succeeds never reports failure. That is, no NFS > garbage with non-idempotent operations. > > Postfix does not promise reliable operation over networked file > systems, thus it has no requirements for network file systems. This is probably not going to happen in Linux without mount options, it has not happened in the past. Effectively, these requirements are not met by *BSD's FFS with softupdates either (rename() and link() are not synchronous there either). Andrew, *BSD has - I'm not telling news here - three mount modes, "async", "noasync" and "sync". noasync is the default, it implies synchronous meta and directory updates. async is like Linux' async: guarantee nothing, I'm not sure about sync, I'd need to look into my man page. FFS softupdates are an addition to guarantee consistent file system state even with "async" -- and all these bets are off when the disk drive acknowledges a "write" before the data is on disk (i. e. write cache enabled voids all these guarantees). However, Postfix' queue seems to be safe with softupdates, but not Postfix' maildir delivery, which I find very unfortunate. Postfix should not put itself under the same artificial restriction that the unmaintained qmail-1.03 suffers from. -- Matthias Andree "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." Benjamin Franklin
