Bug 66409

Sorry, but either you've mistaken your terms, or you're asking an impossible situation.

The atime is changed whenever you read from the file, even if you don't change it. You cannot make indexes for a mailbox if you don't read it (it would be akin to making a summary of a book you've never heard about).

Besides, if your archiving program uses the atime to detect changes, it's just plain broken.

If you didn't mean the atime, but the mtime, then please reopen and change the summary.

Oops! I'm Sorry. I meant the modification time, as shown by 'ls' by default.

If I move a mbox file to ~/Mail and start kmail, the modification time of this file is changed immediately to the current tim, before I even access the folder with kmail.

still no bug, but a misfeature

Subject: Re:  do not Change the mbox on creating index

Yesterday I remembered why we do this (switch from summer time to normal 
time).

The modification time of the mbox file and that of the corresponding 
index file is compared. If the index file appears to be older then we 
regenerate the index in order to prevent mail loss. But it's not 
desirable to regenerate the index unless it's really necessary because 
messages which are marked as deleted will reappear and status flags 
like important, replied, etc. will be lost.

If we wouldn't touch the mbox file just before the index file is written 
then we would falsely assume that the index was out of date if the mbox 
file was changed before the clocks where set back to normal time and if 
the index file was changed afterwards.

We could probably improve our strategy by storing the last modification 
time of the mbox file in the index and checking this stored time in 
case the index appears to be out of date. Then our workaround for the 
summer time -> normal time switch shouldn't be necessary anymore.

Sorry, Ingo, but that doesn't make sense. Your clock did not go back, your timezone went forward. File modification times are stored in universal time, which is not affected by daylight savings or timezones.

Clocks aren't supposed to go back. That is, you're not supposed to have files with modification times in the future. KMail could simply check that the mailbox files have modification dates in the future and, then, touch them. Have you tried running make with a skewed clock?

Subject: Re:  do not Change the mbox on creating index

On Tuesday 28 October 2003 01:55, Thiago Macieira wrote:
> Sorry, Ingo, but that doesn't make sense. Your clock did not
> go back, your timezone went forward. File modification times are
> stored in universal time, which is not affected by daylight savings
> or timezones.

Well, a comment in the source code says that touching the mbox file 
fixes a problem with the daylight saving -> normal time switch. 
That's all I can say. I assumed that the person who made this fix 
actually tested this.

> Clocks aren't supposed to go back. That is, you're not supposed to
> have files with modification times in the future. KMail could simply
> check that the mailbox files have modification dates in the future
> and, then, touch them.

Thanks for the suggestion.

> Have you tried running make with a skewed clock?

No, but we received enough bug reports from people using NFS servers 
with clocks that are not in sync with the clocks of the NFS clients.

Instead of modifying the time of the mail file artificially, wouldn't it be better to check the time of the index file after it has been created, compare it with the mail file and set the index file time so that it is at least a second after the mail file, but leave the mail file untouched?

If this leads to a problem in weird cases where it would be set into the future, then I would at least suggest to touch the mail files only after checking that their date is really in the future, but don't do anything if they are already in the past and therefore older than the newly created index.

It seems to me that it is preferable for a lot of reasons (e.g. backup) that the modification time is only set for files that are actually modified.

Thank you for your feature request. Kmail1 is currently unmaintained so we are closing all wishes. Please feel free to reopen a feature request for Kmail2 if it has not already been implemented.
Thank you for your understanding.

Instead of creating a new feature request, please confirm here if the wishlist is still valid for kmail2.