[EMAIL PROTECTED] 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 [email protected] http://lists.nongnu.org/mailman/listinfo/nmh-workers
