Bill Cole wrote:
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
The question is whether this is because of an fs limitation or is it for
compatibility with some old tools.
Posix says:
Upon successful completion, /rename/() shall mark for update the
/st_ctime/ and /st_mtime/ fields of the parent directory of each file.
and ctime is the last status change time. AFAICT, an mv is certainly a
status change.
but maybe I disgress:)
