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@scconsult.com