[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-bugs-dist
Subject:    [Bug 66880] "Index out of date" completely broken UI-wise
From:       Ingo "Klöcker" <kloecker () kde ! org>
Date:       2003-10-30 0:27:49
[Download RAW message or body]

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.
     
http://bugs.kde.org/show_bug.cgi?id=66880     
kloecker@kde.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |CLOSED
         Resolution|                            |INVALID



------- Additional Comments From kloecker@kde.org  2003-10-30 01:27 -------
Subject: Re:  New: "Index out of date" completely broken UI-wise

On Thursday 30 October 2003 00:56, Markus Baumeister wrote:
> 1) How the heck is a simple change-time check supposed to work with
> NFS? It doesn't have to be 1 hour difference, I was able to reproduce
> it also with ca 30 seconds difference. And don't tell me about ntp.
> Unless you run it every few seconds there is always a chance for a
> time difference in a distributed system.

We allow the mbox file to be up to 5 seconds newer than the index file. 
This should be enough for any distributed system.

> So the minimum necessary 
> would be check for different clocks before using that information for
> such drastic measures: Simply create a file in the ~/Mail directory,
> check its time and if that differs from the local time about the same
> as the index then ignore the "index out of date" problem.

I've tried several tricks similar to what you propose. In each case NFS 
was "smarter" than me i.e. non of my workaround worked reliably.

> 2) The requester poping up is telling lots of things about the
> out-of-date index (BTW, did you know that the embedded FAQ link does
> not work if one chose mozilla as main browser for URLs since "help:
> is not a known protocol"?  KMail seems to rely on browser lock-in).

That's a KDE wide problem then and not specific to KMail.

> But since I very well know that there are no other programs
> manipulating mail-file nor index I am really missing a choice a la
> "Do you want to recreate the index or risk loss of mail?" plus a
> "Yes" and a "No" button instead of the only available "OK". Otherwise
> it looks much as if KMail follows the MS way of "We know it better
> than the user".

We explicitely decided not to let the user a choice because we don't 
want to be held responsible for loss of mail. The normal user is not 
able to decide whether it's safe not to regenerate the index. If you 
think you know better than the developers then please simply hack the 
source code and disable index regeneration in your personal version of 
KMail. This is Open Source after all.

> 3) All wouldn't be too bad if it was actually possible to delete
> mails from the mailfolders. But up to now I haven't been able to do
> so: Delete (with "del" key), Empty Trashcan, Compact Trashcan,
> Compact Folder, Exit program. Nothing helps. Next time KMail
> recreates its index the mail is back. Either it doesn't work or it
> must be a completely unintuitive way in the GUI. I am very much
> considering of going back to Mozilla for reading mail, even though
> that program takes ages to compact folders (at least in its former
> incarnattion as netscape 4.x when I used it last). But at least it
> really compacts folders instead of only faking it to look fast.

Sometimes compaction is disabled (also to protect the user from mail 
loss). I suggest that you convert all your folders to Maildir format. 
This format is much more robust than mbox. One advantage is that all 
messages are stored in a file of there own. Therefore deletion doesn't 
require compaction anymore.

Regards,
Ingo
[prev in list] [next in list] [prev in thread] [next in thread]