Version: 1.5.1 (using KDE 3.1.1) Installed from: SuSE OS: Linux (i686) release 2.4.20-4GB It seems when creating indexes for mbox folders, kmail changes the access time of those mbox folders, although it does not change the mbox files. This is very inconvenient, since the information when the last message was last added is lost, e.g., for archiving and backup purposes.
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.