[Dovecot] Deleting messages from MailDir

[mouss]

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.