On Wed, 10 Dec 2003, Sam Varshavchik wrote:
Chris Ricker writes:
> On Wed, 10 Dec 2003, Ronny Buchmann wrote: > >> If MDA and MUA try to access it at the same time, you run into problems when >> they don't agree on a locking scheme or when using NFS. >> >> Maildirs don't need locking. > > Not true. That's why what passes for the Maildir standard was revised > earlier this year, after people found out the hard way that the "locking > not needed" hype was losing their email....
I'm not aware of Bernstein doing anything like that.
If you're referring to adding milliseconds to the filename, nothing in the revised naming convention requires any kind of locking whatsoever. I'm not sure where that notion came from. Sounds like the usual suspects have been spraying FUD again.
I'm not saying it required locking, I'm saying one reason the revision was needed was due to lack of locking.
If you had some kind of locking in place you'd still have the same exact window of vulnerability, except that you would've had to have a slightly faster CPU/disk before you get nailed.
Look at why the file naming was revised -- PID recycling was causing non-unique filenames w/in a second, which in turn lead to collisions.
One way of looking at that is that the original Maildir convention was fine to still use with locking as protection against concurrency.
The other way of looking at it is that the original standard was broken and truly unique filenames should have been chosen instead. As it
At the time, nobody was recycled PIDs in less than a second. In fact, there were some VERY good reasons AGAINST doing so; because it would've broken some things.
And I still believe that recycling PIDs in this fashion is a dumb idea. The explanation is that randomized PIDs improve “security”. Yes, but at the same time you've just opened up a bunch of new holes.
happens, djb changed the standard (though I don't think qmail got updated?)....
Similarly, what can happen when you mix products which implement Maildirs differently (ie, Postfix LDA does something like time.device#inode#.hostname now, while Mutt appears to still do something more like time.pid.hostname for the uniqueness in filenames)? Shouldn't locking be needed there?
There's an established filename creation convention. As long as everyone follows the same set of rules -- which provide a GREAT deal of leeway -- there's no collision. Even the older format, used by mutt, is not a problem because the collision could only occur if mutt terminates and its pid get recycled in the same second. The filename collision is only an issue for mail delivery agents, which get forked, unload a single message, and exit. It's not an issue for mail clients.
The updated filename generation convention does provide for a format that includes the device and the inode. Since the dev/ino tuple is always unique, there's no chance for a duplicate filename; and as long as the actual format used by Postfix follows the convention, it won't conflict with anything else that uses the same convention.
Attachment:
pgp00092.pgp
Description: PGP signature