Re: SAVEDATE is using ctime instead of btime for Maildir

[Timo Sirainen]

On 19. Mar 2024, at 0.43, Alex via dovecot  wrote:
> 
> Dovecot supports SAVEDATE IMAP extension [1].
> This is however not implemented correctly for Maildir storage.
> 
> Compared to "internal date", "save date" is supposed to be the same
> but well-defined for APPEND and preserved when COPY command is used.
> 
> However, for Maildir storage INTERNALDATE is implemented
> using mtime (modification timestamp)
> and SAVEDATE is implemented using ctime (status change timestamp) [2].
> ctime is changed even more often than mtime.
> For example, chown or chmod operations on the message change its
> ctime, but preserve its mtime.
> 
> Dovecot should instead use btime (creation timestamp) when it is available
> and not implement SAVEDATE at all if there is no btime.

ctime is not perfect, but I don't think it's completely unusable either. 
Normally mail files aren't being chmod/chowned. More troublesome is that 
message flag changes result in renaming the file, which changes ctime. Also it 
rather depends on what the SAVEDATE is used for whether this is a problem or 
not. The main reason SAVEDATE exists is for Dovecot to implement mailbox { 
autoexpunge } setting so mails moved to Trash can be deleted N days after they 
were moved there. For this purpose the current implementation is okay enough.

In any case btime would not be correct, since it would not change when 
copying/moving mail between folders. That is its most important purpose.

I guess we could hide the SAVEDATE capability if none of the configured mailbox 
formats support it perfectly.

> You can read more in the issue [3] where we have problems with incorrect 
> INTERNALDATE
> and investigated the possibility of using SAVEDATE, but found that it is not 
> implemented correctly
> and is changed even more often than INTERNALDATE. According to the standard 
> it should be the other way round,
> SAVEDATE should be more stable and survive COPY.

I don't see why you say it should be more stable. INTERNALDATE is entirely 
stable and never changes once mail is saved, as long as someone doesn't go 
poking the mails directly in the filesystem. SAVEDATE always changes on 
COPY/MOVE.
___
dovecot mailing list -- dovecot@dovecot.org
To unsubscribe send an email to dovecot-le...@dovecot.org

SAVEDATE is using ctime instead of btime for Maildir

[Alex via dovecot]

Dovecot supports SAVEDATE IMAP extension [1].
This is however not implemented correctly for Maildir storage.

Compared to "internal date", "save date" is supposed to be the same
but well-defined for APPEND and preserved when COPY command is used.

However, for Maildir storage INTERNALDATE is implemented
using mtime (modification timestamp)
and SAVEDATE is implemented using ctime (status change timestamp) [2].
ctime is changed even more often than mtime.
For example, chown or chmod operations on the message change its
ctime, but preserve its mtime.

Dovecot should instead use btime (creation timestamp) when it is available
and not implement SAVEDATE at all if there is no btime.

Just one example of the message in Maildir:

stat 1708031310.M769290P3712350.nine,S=7898,W=8002:2,Sa
  File: 1708031310.M769290P3712350.nine,S=7898,W=8002:2,Sa
  Size: 7898Blocks: 16 IO Block: 4096   regular file
Device: 9,2 Inode: 7864351 Links: 1
Access: (0600/-rw---)  Uid: (  999/   vmail)   Gid: (  996/   vmail)
Access: 2024-02-16 08:34:04.374097798 +0100
Modify: 2024-02-15 22:08:30.769813368 +0100
Change: 2024-02-21 13:39:14.878163244 +0100
 Birth: 2024-02-15 22:08:30.769813368 +0100

Its Birth date (btime) and Modify date (mtime) are the same, but Change date 
(ctime)
was changed, likely by someone doing chown/chmod manually.

You can read more in the issue [3] where we have problems with incorrect 
INTERNALDATE
and investigated the possibility of using SAVEDATE, but found that it is not 
implemented correctly
and is changed even more often than INTERNALDATE. According to the standard it 
should be the other way round,
SAVEDATE should be more stable and survive COPY.

[1] 
[2] 

[3] 
___
dovecot mailing list -- dovecot@dovecot.org
To unsubscribe send an email to dovecot-le...@dovecot.org