[Dovecot] Deleting messages from MailDir
mouss
mouss at netoyen.net
Thu Feb 14 19:13:16 EET 2008
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.
More information about the dovecot
mailing list