Re: [Nmh-workers] nmh over sshfs?

[rader]

 > >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
--