Re: locking rcvstore?
I think anytime that there is a possibility of multiple processes writing to the same file, locking should be enableable. Even if it's a command line switch (everyone likes to say use procmail, but this is essentially what procmail does: locks file and folders by default, Not when you're using rcvstore, because then it doesn't know what the folder's called, even whether there is a folder (you could be pushing it into a program that redirects it as formail can or that processes the message fully in some other way). File locking is essential. If semantics mean it can't be done on some platforms, tought for those users, do it where you can. Don't forget to test on nfs-mounted filesystems too; I've had a few programs fail on nfs-mounts - StarOffice and ypbind amongst them. -- Cheers John Summerfield Microsoft's most solid OS: http://www.geocities.com/rcwoolley/ Note: mail delivered to me is deemed to be intended for me, for my disposition. == If you don't like being told you're wrong, be right!
Re: locking rcvstore?
Michael Richardson [EMAIL PROTECTED] wrote: Aside from trashing sequences (which I've experienced on occasion, no idea why) I've run into situations where I wind up doing an inc from two difference sources into the same folder. Usually due to impatience on my part. As far as I know, inc does to file locking, at least when writing to the standard unix mailbox. The result was a mess of two processes using the same message numbers! That should not be possible. I haven't looked at the code. But it should be opening the file with O_CREAT, which should fail if the message already exists. Unless there are major code deficiencies, creating new messages should depend on the atomicity of unix file creation. No additional locking should be required. That is supposed to be one of the benefits of one message per file. -NWR
Re: locking rcvstore?
On July 12, 2002 at 10:18, Neil W Rickert wrote: That should not be possible. I haven't looked at the code. But it should be opening the file with O_CREAT, which should fail if the message already exists. I think you mean O_CREAT|O_EXCL. Unless there are major code deficiencies, creating new messages should depend on the atomicity of unix file creation. No additional locking should be required. That is supposed to be one of the benefits of one message per file. So how is message number (filename) determined? If a open() fails to pre-existance, does inc re-read the directory to determine the next message number, or does it just keep incrementing the number to something works? It seems that the only real place that locking is needed is for the .mh_sequences file. I.e. The use of locking can be limited to areas where there is no non-locking method available to prevent corruption. --ewh P.S. Somebodies formatting of the References: field is messed up. Only message-ids should be present.
Re: locking rcvstore?
From: Earl Hood [EMAIL PROTECTED] Date: Fri, 12 Jul 2002 14:59:12 -0500 It seems that the only real place that locking is needed is for the .mh_sequences file. I.e. The use of locking can be limited to areas where there is no non-locking method available to prevent corruption. Speaking of non-locking methods to prevent corruption, one of the other things I'd like to see done (speaking again as someone who's not going to be implementing it), is to find a way to support Maildirs as well as the current MH directories. (http://www.qmail.org/man/man5/maildir.html) Preferably these would be extended compatibly with courier-imap's Maildir++ so the same hierarchy of messages could be seen in both places. (http://www.inter7.com/courierimap/README.maildirquota.html) Note that courier-imap uses . a the separator character. I don't know why he didn't bother to specify that. This might be a useful first step before an imap backend since it would be somewhat easier. Chris -- Chris Garrigues http://www.DeepEddy.Com/~cwg/ virCIO http://www.virCIO.Com 716 Congress, Suite 200 Austin, TX 78701 +1 512 374 0500 World War III: The Wrong-Doers Vs. the Evil-Doers. msg00969/pgp0.pgp Description: PGP signature
