[ Please don't Cc: public replies to me. ] Christian Schwarz: > > Mailboxes are locked using the username.lock lockfile convention, rather > > than fcntl, flock or lockf. > > This is buggy since it's not working over NFS. It _does_ work over NFS, if you do it properly (i.e., using something similar to my lockfile.c in Publib). It's just that you can't create the username.lock file directly, you must go via an alternative route. The policy manual describes the end result (the mailbox is locked when username.lock exists); it doesn't explain the algorithm. > IMHO, the code in "publib" looks very good. It might be, but I don't know NFS failure modes well enough to be a judge. Problem is, you can't rely on common sense in this case, since some of the failures in networking (in general) are _really_ hairy, and you must understand things very thoroughly to get things exactly right. I think we should use the maillock interface of System V, since that already exists and seems to work. It will be less work for us and for upstream authors to use existing interfaces, where they work. > In addition, we could create a new "lockfile" binary (just as in procmail) > that can be used by shell scripts or other programs (via "system"). The interface should be "maillock username", so that the callers of the program (or the C library function, for that part) don't need to know that a lockfile is used, or where it's placed. That will allow us to change things easier in the future. (The lockfile program in procmail can't do that, since it is needed to lock files in other places as well.) -- Please read <http://www.iki.fi/liw/mail-to-lasu.html> before mailing me. Please don't Cc: me when replying to my message on a mailing list.
Description: PGP signature