> >bash$ diff -u lock_file.c.orig lock_file.c > >--- lock_file.c.orig 2008-04-05 13:41:37.000000000 -0500 > >+++ lock_file.c 2008-10-18 09:53:03.000000000 -0500 > >@@ -365,6 +365,9 @@ > > if ((fd = open (file, access, mode)) == -1) > > return -1; > > > >+/* SR HACK */ > >+return fd; > >+ > > /* > > * Get the name of the eventual lock file, as well > > * as a name for a temporary lock file. > > The trouble with this is that it's in the file locking > function (I know you said this was just a hack but I thought > I'd point out the pitfalls in advance). Any changes to this > have to be very carefully audited because the same function > is used for locking the mail spool. So the code has to both > work in and of itself (ie two nmhs mustn't tread on each > others' toes) but also with any other implementation of the > dot-locking algorithm, including nasty cases like running > over NFS. Bugs here will mean very occasionally corrupted > or lost mail.
I just did some googling on this. It seems that link() is really required when dealing with mail spools because it's the only atomic way to lock. So this whole "no-links configuration option" idea is a bad idea, and I now realize that I'll never be able to safely inc over sshfs. Shoulda just used AFS in the first place: it's got encryption, link(), speedy client side caching, and the usual CW against using AFS for a mail spool (other systems' callbacks cause you to wait) doesn't really apply for a single user mail server. steve -- _______________________________________________ Nmh-workers mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/nmh-workers
