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:)