On Fri, Jul 03, 2009 at 01:45:50PM +0200, Rocco Rutte wrote: > This an example to outline a proposed solution, I know, but how about > mkdtemp()? Hard-coded temporary file/directory names beg for trouble. Sure, if you were going to try to implement something like this, mkdtemp is the right place to start. But it only solves about half the problem -- specifically it solves the naming exclusivity problem. But it doesn't solve the other aspects of the problem that I outlined. It also introduces a new complication: mkdtemp() honors $TMPDIR. So if the user has that set, Mutt has no idea where the directory will be created, unless it goes to the trouble of manipulating $TMPDIR each time it needs to remove a maildir folder. Since the files need to be moved atomically, that's important for the same reasons I outlined before. > I think you also get strange semantics if a messages is > delivered/appended to 'mdir' between the mkdir() and rename() calls? > Both calls would succeed but you would fail to remove > 'mdir-mutt-delete'. Ultimately this is the problem which, as far as I can tell, is insoluble. To decide whether it should be removed, you need to make sure it is empty. Then you need to rename it. You can not do this atomically, so it's always possible that after you check for emptiness, but before you rename it, a new (or old) message could be added to the folder by the MDA or some other outside process. This would pretty much guarantee that at some point, you're going to lose mail. The Maildir format was not designed for this... One might be tempted to "lock" the directory by making it non-writable. But this approach can not be done atomically either, because you need to do so for all of $mdir/cur, $mdir/new, and $mdir/tmp. It's tempting to think that doing this for new is enough, but Mutt can't guarantee that, as it doesn't have specific knowledge of how other tools might be manipulating the other directories. It's also (I think) not determined how the MDA will behave if it tries to deliver a message to an unwritable directory. [The behavior of a given MDA can be determined, but it can't be guaranteed that all MDAs will behave the same way.] It's simply not reliably safe to implement this, any way you slice it. Personally, I'm a proponent of the idea that the interface should be consistent regardless of the folder formats; I'd prefer that the feature either be removed or emulated where it doesn't actually work. If Mutt can determine that a folder is empty, there's no reason it has to present it to the user any place where it might normally do so... But if you're going to do that anyway, might as well do it for all formats, and save the filesystem operation(s) necessary to actually remove the file safely. -- Derek D. Martin http://www.pizzashack.org/ GPG Key ID: 0xDFBEAD02 -=-=-=-=- This message is posted from an invalid address. Replying to it will result in undeliverable mail due to spam prevention. Sorry for the inconvenience.
Attachment:
pgpKePIMtAQqt.pgp
Description: PGP signature