Re: [Dovecot] Move deleted to trash
On 25.7.2007, at 16.02, Donald Nash wrote:
EXPUNGE command is specified to expunge the mails, not move them to
another mailbox. This would make having the message really gone a 4
stage operation: Mark deleted, expunge, mark deleted in Trash,
expunge Trash.
In many clients when you mark a message deleted it also copies it to
Trash. So a server side expunge-to-trash feature causes the message
to get copied there twice.
A Trash mailbox also has the problem that all of your messages get
there. There's no way to have an easy "unexpunge" operation, because
the original mailbox isn't saved anywhere. You have to manually copy
the message to the wanted mailbox.
Perhaps lazy-expunge is a bit similar, but it preserves the mailboxes
and doesn't conflict with clients' move-to-Trash feature. Also the
concept in general is about having easily restorable backups of mails
and not some kind of a idea that mails should go to a Trash mailbox
when they're deleted.
Maybe that whole Trash concept is the reason I consider it evil. I
don't like that Trash concept in desktop environments either. I wish
the undelete feature was in filesystems, so that when disk is full,
the oldest deleted files would automatically get overwritten with new
data, but until then the files would be undeletable.
I think I'd prefer the lazy-expunge way for that more than having
everything go to Trash. The virtual Trash would make client-side
"delete=mark deleted + copy to Trash" feature unnecessary.
Well, I Cc'd the list now.
Evilness is subjective. :)
--On July 25, 2007 4:55:06 PM +0300 Timo Sirainen <tss@iki.fi> wrote:
This same complaint can be lodged against lazy-expunge. The cure, of course, is for the server to keep such folders (whether they are trash folders or the more complicated hierarchies that lazy-expunge creates), cleaned up by expunging messages older than a certain age. You're working on that with the Expire plugin. Other IMAP servers I've seen which implement a server-managed trash folder do this specifically for the trash folder. In either case, it means you can continue to use the the "mark deleted, then expunge" model, and not worry that the messages are really just being moved somewhere else temporarily.
So turn it off in one place or the other. Every mail program I've looked at that implements a client-managed trash folder located on the IMAP server has a configuration setting for turning it off. Or you can turn it off on the server if you'd prefer that clients do it for themselves.
This seems like a moot point to me. A proper unexpunge operation cannot exist until either it is added to the IMAP standard, or something like lazy-expunge gets enough traction for the authors of IMAP clients to start writing code to use it (have any done so?). Until then, restoring deleted messages directly from the IMAP client will always involve having the user find the proper folder and copy the message elsewhere. This is exactly what he'd have to do to retrieve the message from a trash folder, except it is somewhat more complicated because of the need to find the right folder containing the expunged message.
As mentioned in the documentation for lazy-expunge, you could have a web interface to handle unexpunging. While this would be useful for restoring large groups of messages or entire deleted folders, it is still something of a hack because it is done "behind the back" of the IMAP client. I'm not saying it isn't worth doing, just that I wouldn't call it a *proper* unexpunge operation (I'm defining "proper" as meaning "available directly from an IMAP client", others may have different definitions). It also isn't supplied with Dovecot, so it would either need to be written from scratch or obtained from someone else who has already written it.
Both features are fundamentally about the same thing: being able to recover messages which should not have been deleted. Also, they both involve taking messages which are being expunged and copying them to another folder prior to expunging them (thus arguably violating the strict definition of "expunge"). The only technical difference is the folder to which they get copied. That technical difference makes for a big functionality difference, and lazy-expunge is therefore a more comprehensive solution. But this comes at the expense of being a bit harder to use in the trivial cases.
The virtual Trash would make client-side "delete=mark deleted + copy to Trash" feature unnecessary.
Except that's not how client-side trash folders work, at least not the ones I've seen. They don't move a message into the trash folder until you expunge it, not when you mark it for deletion.
Well, I Cc'd the list now.
And since this has turned into much more of a discussion than I anticipated, I've done what I should have done in the first place and joined the list.
-- Donald L. Nash, <D.Nash@its.utexas.edu> Information Technology Services, The University of Texas at Austin
participants (2)
-
Donald Nash
-
Timo Sirainen