From kmail-devel Mon Jul 21 23:27:58 2003 From: Ingo =?iso-8859-1?q?Kl=F6cker?= Date: Mon, 21 Jul 2003 23:27:58 +0000 To: kmail-devel Subject: Re: ClientInterface X-MARC-Message: https://marc.info/?l=kmail-devel&m=105883162629899 MIME-Version: 1 Content-Type: multipart/mixed; boundary="--===============8039920464031991==" --===============8039920464031991== Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Boundary-02=_EcHH/KFrt9DiHP0"; charset="iso-8859-1" Content-Transfer-Encoding: 7bit --Boundary-02=_EcHH/KFrt9DiHP0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Monday 21 July 2003 05:10, Don Sanders wrote: > On Sunday 20 July 2003 23:29, Ingo Kl=F6cker wrote: > > On Sunday 20 July 2003 13:36, don@sanders.org wrote: > > > The problem is KMail can't handle foreign processes modifying > > > it's index files, especially while KMail is running and the > > > folder for that index file is opened. It's equivalent to having a > > > foreign process corrupt memory in the KMail process. > > > > No. It's not. If the index files are locked then at any time only > > one KMail can modify them. Of course the index file must not be > > locked the whole time a certain folder is visible but only if the > > index file is accessed. > > It is a problem. Currently we hold open an index file while a folder > is opened. E.g. I have a mainwindow showing my kmail folder currently > and it will remain open as long as I'm looking at that folder. With > the current KMail architecture we would have to lock the index file > for as long as the KMFolder is open, as while the KMFolder is opened > their exist KMMsgInfo objects that point into the index file and > perform read/writes into the index file. > > If the index file is modified while those KMMsgInfo objects exist > then those objects may end up pointing to bogus file offsets and > consequently end up corrupting the index. > > Are you suggesting we redesign KMail so that it does not keep folders > open? And change KMail so that every time an action is performed on a > message KMail opens a folder reads in the index, performs the action, > then closes the index and folder? Yes, something like that. Of course the index should only be reread if=20 the index file was changed by someone else. But the index file would=20 have to be written each time something has been changed. And keeping=20 the folder open is really only a problem with mbox. With maildir this=20 problem doesn't exist. With mbox we could still keep the file open in=20 read-only mode. Since we don't write any status information back to the=20 folder files writing to mbox files is only necessary under two=20 circumstances: a) When a message is added. b) When the folder is compacted. And the only problematic action is the compaction. > > > Also, to be honest I would prefer to avoid a maildir only > > > limitation also. > > > > Why? > > Because it's an unnecessary limitation that is not jusitified. That's your opinion. > > > made by the second client? Poll the index file, and completely > > > reparse it whenever changes are made? > > > > Exactly. You know that KDE provides easy-to-use classes for > > watching files, right? > > It's not watching the files that is the main problem. The problem is > retaining the integrity of objects that point into files which can be > changed by other processes. Nobody said it would be easy. But it's definitely far from being=20 impossible. And, I have to repeat myself, this is only a problem for=20 people who use multiple instances of KMail at the same time. They will=20 have to live with a reduced performance. > > > Another problem is serial numbers, if there are multiple clients > > > each with their own serial numbers then duplicate serial numbers > > > are going to be assigned. > > > > This could be avoided by writing the next possible serial number to > > a file or, probably even better, by simply touching a file called > > 12345 in ~/.kde/share/apps/kmail/serialnumbers/ where 12345 is the > > next available serial number. Each time a new serial number is > > needed KMail would look for this file, probably use a locking > > method to avoid a race condition, and then write/touch a new file. > > Of course this would be slower than a memory only solution. But at > > least it shows that the serial number problem is solvable. And it > > does even work for several KMails which run on different machines > > accessing the same home directory via NFS which the client/daemon > > solution can't solve. > > I'm under the impression that NFS clients cache the list of files in > directories. In which case this doesn't solve the problem for NFS. The NFS clients should be notified by the server in case the list of=20 files changes. Whether this really happens is unfortunately more than=20 questionable. All the problems that we have with NFS mounted ~/Mail=20 directories show that NFS doesn't really work as advertised. And that's=20 probably the real showstopper. Regards, Ingo --Boundary-02=_EcHH/KFrt9DiHP0 Content-Type: application/pgp-signature Content-Description: signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3rc1 (GNU/Linux) iD8DBQA/HHcEGnR+RTDgudgRAhZzAJwIBk4ujlx9ne/ogI55AaM/7mU2PgCgqkeR 8jVWa5VUTRulQFj/KO2MtcY= =xK5v -----END PGP SIGNATURE----- --Boundary-02=_EcHH/KFrt9DiHP0-- --===============8039920464031991== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ KMail Developers mailing list kmail@mail.kde.org http://mail.kde.org/mailman/listinfo/kmail --===============8039920464031991==--