Marcus Williams writes:
> Hi -
>
> [this message is probably only of interest to people running a
> development version of vpopmail (post 4.10.3) with their domains on
> NFS mounted drives]
>
> I noticed in a recent version of vpopmail (version 4.10.3), the
> delivery method (deliver_mail) has stopped delivering to the
> Maildir/tmp (from now on referred to as /tmp) directory first in order
> to remove a system call to rename from the code (the /tmp file was
> then linked to Maildir/new - referred to from now on as /new).
>
> I've been looking at the new code (version 4.10.14) and it appears to
> be going straight to the /new directory now which is incorrect if you
> are trying to follow the Maildir algorithm (that ensures
> safe/guaranteed delivery, requires no locking under NFS etc). The
> whole point of delivering first to /tmp and then linking this file to
> /new is to stop corrupt messages ever hitting Maildir/new and to
> ensure reliable delivery under NFS failures/machine crashes etc. Once
> a message is linked from /tmp to /new (and then stat()'d to make sure
> its there) the idea is that it guaranteed not to be
> incomplete/undelivered. After linking it to the /new area, assuming
> there is no error we can remove the /tmp file.
>
> With the development versions (4.10.3+) if the server crashes during
> delivery (mid file write) this will leave a corrupt message on the
> server in the /new delivery area, something the Maildir format is
> designed not to do.. Admittedly Qmail will probably try and redeliver
> the message as it has not been delivered successfully but without the
> initial delivery to /tmp a user can receive corrupt messages.
>
> There is also a bug for NFS in that fsync() (or fdatasync?) is not
> called on the file vdelivermail writes to in the delivery area so you
> do not guarantee it has actually been written. This means the file can
> be successfully delivered according to vdelivermail but in reality
> only locally cached and not written out (commited?) to the NFS drive.
> Vdelivermail will have returned success but if the machine crashes at
> this point the mail can potentially disappear if the NFS mount doesnt
> recover properly.
>
> Is there any reason (other than optimisation) that these calls have
> been removed (or in the case of the missing fsync not implemented)?
Yes, there is another reason. I like to get about 8 hours of
sleep a night :)
Ken Jones
