Bill Cole wrote:
At 11:53 PM +0100 2/13/08, mouss imposed structure on a stream of electrons, yielding:
Bill Cole wrote:
[...]
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:)
Since nothing but your POSIX quote refers to the ctime of the parent directory, maybe so. :)
yes, I realized that thanks to friendly heads ups :)
I think that when you rename() (i.e. 'mv') a file, its ctime should change, if only because that is what traditional (e.g. UFS) filesystems do.
some might argue that this is not necessarily the "right" behaviour in the case of multiple hard links...
In the case under discussion, I think that using the last mv time is safer. If I move a message to the Trash, I might regret it and try to go save it. if the delivery date was used, the message may have been expunged. so updating the ctime will cause less surprises.
I know better than to argue technical issues like that with Apple, just as I know better than to use my head to dismantle a brick wall, with the main difference being that I've never actually made the brick wall attempt.
:)
But the relevant point is that Dovecot itself seems untroubled by this oddity.