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

List:       kmail-devel
Subject:    Re: How to make KMail play nice with mutt and procmail
From:       Ingo =?iso-8859-1?q?Kl=F6cker?= <ingo.kloecker () epost ! de>
Date:       2002-02-02 11:00:02
[Download RAW message or body]

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

On Saturday 02 February 2002 09:16, Michael Häckel wrote:
> On Freitag, 1. Februar 2002 22:21, Ingo Klöcker wrote:
> > AFAIK we currently only store the mtime of the mailbox files in the
> > index files. This seems to cause problems with mutt as it doesn't
> > change the mtime for some reason.
>
> According to Dirk's comments it seems that it even has a reason for
> that. It abuses the modified timestamp to determine if there are new
> mails or not instead of treating it as any other application treats
> any other file.

That was a bad design decision by the mutt developers because it makes 
mutt not play nice with any other MUA. It's really a pity that we would 
have to work around this.

> > Maybe we should also store the size of the mailbox file. If mutt
> > changes the file it's size will almost certainly change (and if it
> > doesn't change then the change which mutt made is most likely no
> > problem).
>
> Well, this is something that works nearly always but not 100%
> reliable.

We'll at least notice the following changes with 100% reliability:
- - mutt adds one of its proprietary headers to some messages.
- - procmail adds some new messages to the folder.

The only problem might be if mutt adds some headers/messages and deletes 
some messages almost at the same time so that the filesize stays the 
same. This is very unlikely to ever happen. We'd anyway have to check 
all folders every few seconds for new messages added by procmail (and 
not only when they are accessed). And then it's even more unlikely that 
a change isn't noticed by KMail.

> > If we detect a change then we must of course recreate the index.
> > But we could try to do this without loosing the message flags by
> > "merging" the old index and the new index, i.e. by copying all
> > message flags from the old index to the new index (we should have
> > enough information to identify corresponding messages in both
> > indeces).
>
> I don't think that we have. Anyway I still think, we should somehow
> write the status back in the mbox files.

I agree. But not immediately. Only if the folder is compacted. Or maybe 
also if the folder is closed. It would of course be preferable if we 
didn't have to rewrite the whole file but could simply change the 
status values in the Status and X-Status header.

> > If we implement this we would finally solve all problems with the
> > interoperability of KMail with mutt, procmail and possible other
> > KMail clients running on a different machine but accessing the same
> > mailbox files over NFS.
> > What would be the best locking method? procmail lockfile or mutt
> > dotlock?
>
> These locking methods all have the problem, that they leave stale
> lock files, if KMail crashes, therefore we probably have to use FCNTL
> which however doesn't work on NFS. It should be checked, how mutt and
> pine do that.

FCNTL is not an option because making it work with NFS is much more 
important than preventing stale lock files because of crashes.
Reason 1: KMail simply shouldn't crash. ;-)
Reason 2: People who use mutt or procmail will most likely know how to 
remove stale lock files.

Regards,
Ingo
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE8W8a1GnR+RTDgudgRApUHAJ43ZPDY5meLE6IP/DT5Jo3K/D+qrgCgkn/E
Xl+1WMBSa9Md5IumvwSvb/g=
=lafw
-----END PGP SIGNATURE-----
_______________________________________________
kmail Developers mailing list
kmail@mail.kde.org
http://mail.kde.org/mailman/listinfo/kmail
[prev in list] [next in list] [prev in thread] [next in thread]