[EMAIL PROTECTED] writes: > Excerpts from mail: 20-Nov-01 Re: [OpenAFS] mail spool on.. Patrick > [EMAIL PROTECTED] (1724*) > > > Too bad you did not take one more step; you could have invented > > maildirs and avoided the need for any locks at all. > > > See http://cr.yp.to/proto/maildir.html, but my quick summary is as > > follows: > > > A maildir is a directory hierarchy that looks like this: > > > maildir > > maildir/tmp > > maildir/new > > > To deliver a message, the MTA writes it as a new file under tmp, syncs > > it, and renames it to put it under new. Clients look for messages in > > new, not tmp, so they never see any message until it has been fully > > written. This obviates the need for locks. > > Not a bad idea. But our solution, with locks, also prevents > collisions between multiple simultaneous mail deliveries, as well as > the occasional multiple simultaneous mail readers, not just > single-threaded mail delivery vs. single-threaded mail reading.
Maildirs have no problem with concurrent deliveries; the MTA uses a unique file name (timestamp.pid.hostname) for each message, so independent MTAs will never collide. Multiple concurrent readers only pose a problem if more than one of them tries to *modify* the message simultaneously. djb suggests keeping flags (read/replied/forwarded/etc) in the file name, which means that clients never need to modify the message itself. You can still get "funny" behavior if two clients try to mark a message as read simultaneously, as one of their attempted rename() calls will fail. But actual corruption of the message and flags is still impossible because rename() is atomic. You could also just have the client write a new file and rename() it into place whenever it needed to alter the message; that would also avoid any potential corruption. - Pat _______________________________________________ OpenAFS-info mailing list [EMAIL PROTECTED] https://lists.openafs.org/mailman/listinfo/openafs-info
