(Illustration by Gaich Muramatsu)
On 20 Jan 1999, Magnus Ahltorp wrote: > > It's a good puzzle to see if Coda's connected semantics allow for the > > atomic creation of a lock file. Perhaps that is just possible. On the > > other hand, I don't really have much more faith in AFS or NFS without lock > > daemons when it comes to my mail. > > There are advisory locks in AFS, so mail handling would probably work, > but AFS isn't designed for databases (I consider it a database if more > than one mail is present in the file). I wouldn't recommend doing > it. You're better off with MH mail boxes. A month or two ago, I converted my personal procmail filtered Mail/ directory over to the qmail-style 'Maildir' format. I did this expecting to move my Mail directory over to coda sometime, since I have several machines at home. Pine (and the imapd provided with pine), procmail, mutt, and a couple of other mail clients have patches for maildir style mailboxes. maildir style mailboxes are safe for NFS, even though NFS does not provide safe locking. Basically, each message is a separate file, and the file name contains a timestamp and the message read/deleted/marked flags. There are three subdirecories tmp/ new/ and cur/ in each mailbox folder. New messages are written by the MDA in tmp/ and (atomicly?) moved to new/ when writing is complete. The mail client then moves files from new/ to cur/ when read. Since maildir is nfs-safe (*without* using lockfiles), I believe it would work quite well on Coda. However, since each message takes a file, you will start eating up the 256000 file limit with a lot of users. If conflicts occur, you might have 1 or 2 conflicting mail messages, but you wouldn't lose the whole mailbox or ability to deliver mail. -------------------------------------------------------------------------- | Troy Benjegerdes | troy_at_microux.com | hozer_at_drgw.net | | Unix is user friendly... You just have to be friendly to it first. | | This message composed with 100% free software. http://www.gnu.org | --------------------------------------------------------------------------Received on 1999-01-20 14:44:32