rader(_at_)hep(_dot_)wisc(_dot_)edu wrote:
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 seem to recall somebody who wanted nmh to work on some
other non-Unix-semantics filesystem posting here a while
back. Perhaps there is mileage in separating out the locking
functions we use for nmh-internal files from what we use
for the mail spool -- this would make it easier to accommodate
this sort of use case without compromising spool file locking.
-- PMM
_______________________________________________
Nmh-workers mailing list
Nmh-workers(_at_)nongnu(_dot_)org
http://lists.nongnu.org/mailman/listinfo/nmh-workers