On Mon, 5 Jan 2004, Timo Sirainen wrote: > > the problem with traditional UNIX mailbox format is that > > shared access itself is a problem > I don't think it's that much of a problem. It may be slow when other > applications modify it though. My plan is: > - whenever mtime or size changes "unexpectedly", resync everything
Resync is a problem. You have to scan the entire mailbox in order to locate all the messages. You can't just say "message 1021 didn't move, therefore messages 1-1020 didn't move" -- consider the case of a flag added to one message and removed from another. Preallocated space for flags would help, but it turns out that some legacy UNIX tools remove extra spaces. At least the task is a little bit easier if you store UIDs with the message, rather than having to infer "same message" from message contents. > - whenever we modify or sync the mailbox, keep shared lock for two extra > seconds so we can be sure that we're the only one who did modifications > at a given mtime The only trustworthy lock on a mailbox file is the .lock file which is an exclusive lock. You have to do the other locks too, but .lock is the only one that prevents bad things from happening. Traditional UNIX mailbox format really sucks. You only want to use it if you must support legacy UNIX tools. And if you support legacy UNIX tools, you have to consider the damn stupid things those legacy tools do. If you don't have to support legacy UNIX tools, you'll save yourself considerable hair-pulling by using a more sensible mailbox format that considers shared access from the onset. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum.
