X-Mime-Autoconverted: from 8bit to quoted-printable by mimegpg Content-Type: text/plain; x-avg-checked=avg-ok-2C884472; format=flowed; charset=UTF-8 Content-Disposition: inline

Huaikun Lin writes:

The problem is that removing messages is a two-step process. First, the message must be marked as deleted. Then all deleted messages are removed.

This is how IMAP is designed. There's no other way to remove messages, except for this two-step process.

Marking the message as deleted is, essentially, a file rename operation. If you run out of disk quota, and your rename operation needs to use an additional disk block to process the rename() operation (for the new directory entry), you may not be able to do it. The system won't let you.

Another possible cause for this problem is that your IMAP client implements the delete operation by trying to place a copy of the message into the Trash folder, before actually trying to delete it in the current folder. Obviously, with a full disk quota, that's not going to happen.

Just like with a straightforward delete operation, there is no straightforward "move" operation in IMAP. Messages are moved to a different folder by first placing a copy of the original message in the new folder, then afterwards deleting the original message (using the same two-step process). Meaning that when you begin approaching your disk quota, you will no longer be able to move messages between folders, even if you still not up to the quota limit for the mailbox.

I just can't help but make a side observation that these kinds of clumsy ways of doing basic stuff with mail, via IMAP, were one of the reasons why I designed and implemented the experimental SMAP protocol, in Courier-IMAP 2.x. SMAP has a simple “remove”, and a simple “move” operation (and still offers an IMAP-like copy/delete/expunge paradigm for those that still want to do it this way) which will never have a problem if the disk quota is full.