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
[EMAIL PROTECTED]
