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
Nmh-workers(_at_)nongnu(_dot_)org
http://lists.nongnu.org/mailman/listinfo/nmh-workers