[Dovecot] Deleting messages from MailDir

[Bill Cole]

At 12:21 AM -0500 2/13/08, Benjamin R. Haskell  imposed structure on a stream of electrons, yielding:
>On Wed, 13 Feb 2008, Rody wrote:
>>Op woensdag 13 februari 2008 00:43, schreef Bill Cole:
>>>Yes, but you may also care that ctime is reset when a client has
>>>Dovecot move a message from one subfolder to another within a
>>>Maildir. I'm not sure why Dovecot does it, but a look at the messages
>>>in the non-INBOX parts of my Maildir reveals that the ctime is always
>>>later than the mtime, and the contents (Received headers) makes it
>>>clear that Dovecot sets the mtime of messages to the original mtime
>>>(i.e. original delivery time) when copying them.
>>>
>
>I think the answer to "why Dovecot does it" is actually that Dovecot doesn't do anything with ctime. Under most *nix filesystems, ctime is the last time the inode underlying the file/dir was changed ('c' for "changed", not "created" -- [usually]). The inode gets changed when the file's moved from one directory to another.

Not on all filesystems. Note what HFS+ (MacOS) does:

~ $ ls -lc foo
-rwxr-xr-x   1 wkc  wkc  332 Jan 29 03:32 foo
~ $ mkdir foodir
~ $ mv foo foodir
~ $ ls -lc foodir/foo
-rwxr-xr-x   1 wkc  wkc  332 Jan 29 03:32 foodir/foo
~ $ date
Wed Feb 13 08:39:24 EST 2008



>>>Hopefully Timo will speak up on this, but I have a vague recollection
>>>of him saying that Dovecot never modifies message contents as a
>>>matter of principle, and it seems to me that the design of Maildir
>>>assumes that the mailstore server follows that principle rigorously.
>>>That should make mtime quite static for an individual file, and it
>>>looks to me like Dovecot even makes an effort to preserve the
>>>delivery time of a message by replicating the mtime from the original
>>>file to the new one when copying a message between subfolders.
>
>The delivery time can also be determined by the first part of the Maildir filename of the message:
>
>e.g. ls -l 1202878863.24522_1.myhost:2,
>--rw------- 1 user group 551 2008-02-13 00:00 1202878863.24522_1.myhost:2,
>
>The 1202878863 part is the Unix timestamp corresponding to midnight, Feb 13, 2008 EST. So, it's not really a requirement of Maildir's design to keep the mtime updated. It's just easier+quicker than parsing the number out of the filename (where it *is* a requirement).

Maildir DOES NOT require a timestamp in the filename, it's just common.


On my system, the timestamps in the filenames match the ctime, NOT the
mtime:

~/Maildir/.Tagged/cur $ ls -lcrt |tail -1
-rw-------   1 wkc  staff    13293 Feb 12 23:45 1202877918.P26840Q0M183345.toaster.scconsult.com:2,S
~/Maildir/.Tagged/cur $ ls -l 1202877918.P26840Q0M183345.toaster.scconsult.com\:2\,S
-rw-------   1 wkc  staff  13293 Feb 12 23:43 1202877918.P26840Q0M183345.toaster.scconsult.com:2,S
~/Maildir/.Tagged/cur wkc$ uepoch 1202877918
1202877918 is Tue Feb 12 23:45:18 2008

The earlier mtime matches the delivery time.


>>[...] It looks like the use of ctime or mtime depends on wether you want the message removed x days after it was moved to say the trash folder (ctime) or will be removed x days after it originally arrived in the inbox (mtime). My personal opinion is currently that i would like it removed x days after it was placed in a certain folder, hence i use ctime.
>
>Depends on the context for me. If it's in a spam folder, I'd rather not keep it around any longer than it'd take for someone to say "Hey, didn't you get that?". So -mtime +13 (2 weeks from receipt). (Thanks for the heads-up on +13 vs. +14, btw).
>
>Trash on the other hand, seems like you'd want X to be "about a month" in: "Oh, no! I accidentally deleted that thing X ago!", since messages tend to stick around for a while in the INBOX. (Note the difference: "Oh, no! I accidentally deleted that thing that *arrived* X ago!".) So, -ctime +30 (trashed more than a month ago).
>
>Another consideration for ctime is that changing a message's flags (/keywords) alters its ctime (since the underlying operation is a rename, which alters the inode). (Not sure where that might come into play in the spam/trash examples, but it might be good to know.)


Again, that is FS-specific, and HFS+ is again a counter-example.

(one can argue that HFS+ is Bad and Wrong in many ways, but it is in widespread use...)


-- 
Bill Cole                                  
bill at scconsult.com