On Sat, 2003-03-08 at 19:47, Andreas Aardal Hanssen wrote: > >2. There's a small possibility of temporarily losing mails if it's flags > >keep changing (ie. the filename changes) while the directory is being > >scanned. Although this also depends on how filesystem's readdir() > >handles renames.
> "Why should I use maildir? Two words: no locks." > > I may well be wrong, but I haven't found a way to implement IMAP over > Maildir without locking the depository during a scan. In that sense, I > agree that Maildir is not suited for IMAP (or the other way around). And what are you locking since Maildir doesn't have locks? Your own specific lock file that no others use? That isn't very interoperable. That is anyway what I meant with the 2. above. If file is renamed while you're scanning the directory, you may not see it at all and think it's deleted. Next scan will find it again and show it as new mail. I don't know how readdir() usually works, but if rename()d file shows at least once with new name, old name or both you can deal with that: Both -> you see a conflict, you try to fix it and see that the other file doesn't exist anymore. Old -> open() fails later and you rescan the directory to find the new name. But sure, as long as IMAP server locks the Maildir it can work fine as long as other MUAs aren't modifying the message flags. Even then it's very difficult to hit the condition when file isn't seen with readdir().
