[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Policy wrt mail lockfile (section 4.3)



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


Attachment: pgpw7rakaWLq_.pgp
Description: PGP signature


Reply to: