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

List:       kmail-devel
Subject:    Musings on ghost messages
From:       Till Adam <adam () kde ! org>
Date:       2004-04-28 19:15:50
Message-ID: 200404282115.56458.adam () kde ! org
[Download RAW message or body]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

The "ghost messages in the outbox" thingie bothers me, it really does. So 
while sitting on my beautifull balcony watching the sun set over the baltic 
sea, my thoughts krept back to that particular mistery and by Jove, I think I 
found the reason at last. Maybe not, though, so please tell me if this 
scenario could cause it:

- - user hits send in the composer
- - mail enters outbox
- - box gets new timestamp
- - index is updated, get's new timestamp

let's call that point in time A

in the normal case, the following happens

- - mail leaves outbox
- - outbox get's new timestamp        <= B
- - index is _not_ updated
- - eventually folder is closed
- - index get's new timestamp          <= C

In case of a crash, C is never reached, therefor the index is out of date, it 
contains entries for already gone messages, the ghosts.

Now, usually on the next open of the folder, the uptodate check notices that 
the folder and index are out of sync and nukes and reproduces the index. Why 
does that sometimes fail, though, and why does it only (or much more 
frequently than with other folders) happen with the outbox? Well, the 
uptodate check has a 5 second fuzzyness factor, to avoid constant index 
regeneration with nfs mail stores with slighly skewed clocks. The problem 
with the outbox could very well be that it is the one mailbox where mail 
leaves the folder within 5 seconds of arriving in it, and since leaving the 
folder doesn't update the index, but updates the timestamp on the box/folder, 
the ghost messages happen only in that scenario. So the problem is that if A 
and B are within 5 seconds of each other the uptodate check compares the 
index's timestamp (A) with the outbox's (B) and finds them to be within the 
limit, which is wrong.

Does that make sense? And if so, how do we remedy it?

Till
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)

iD8DBQFAkALstrsWGirveVsRAj/RAKCFsNWT2B+PJU4ovbgD71kIjqPmeACg77ik
AlYjFYxIxp8CHN/nN5+10Tk=
=9csg
-----END PGP SIGNATURE-----
_______________________________________________
KMail developers mailing list
KMail-devel@kde.org
https://mail.kde.org/mailman/listinfo/kmail-devel

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