[Dovecot] Simulating UW Snarf...

[Timo Sirainen]

On Wed, 2006-02-08 at 14:18 -0500, Todd Piket wrote:
> After many lengthy discussions our thought was this.  Could we 
> symbolically link the user's "Maildir/new" to a non-quota file system 
> such that the move from "new" to "cur" would fail if the user is over 
> quota?  What will Dovecot do in that failure situation?  Do you have 
> other suggestions?  I would be more than willing to develop a patch that 
> makes this an option in the config file.  Probably similar to allowing 
> the indexes and control files be on a non-quota file system.  Again, it 
> would only allow "Maildir/new" to be on a separate file system, not the 
> whole "INBOX".  I hope this conveys the idea well enough.

There's one problem with this. rename() doesn't work across filesystems,
so if you did this it would have to be done by first copying the mail to
tmp/, then rename()ing it to cur/ and unlink()ing from new/.

That also has the problem that it's not atomic. If Dovecot was the only
software reading the maildir, it perhaps wouldn't matter as Dovecot
locks the whole maildir while it's synchronizing the mailbox. Also if it
got interrupted in the middle and the unlink() wasn't done, the mail
would get duplicated (the base filename should be changed while copying
to make this problem less worse).

Actually you'd need to have two tmp/ directories, one which the delivery
agent uses and rename()s the mail into new/, and second which the new/
-> cur/ copying uses.

Perhaps the potential duplication-in-error-conditions could also be
avoided with some even more maildir standard breaking.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://dovecot.org/pipermail/dovecot/attachments/20060208/1f2bde5b/attachment.pgp