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

List:       kmail-devel
Subject:    Re: Bug#45545: marked as done (Mail disappears from inbox) by Carsten Burghardt <cb@magic-shop.de>
From:       Don Sanders <sanders () kde ! org>
Date:       2002-07-30 5:27:44
[Download RAW message or body]

On Tuesday 30 July 2002 07:37, Ingo Klöcker wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On Monday 29 July 2002 10:52, Don Sanders wrote:
> > On Monday 29 July 2002 01:17, Ingo Klöcker wrote:
> > > I tried to workaround this problem by touching the index file
> > > after it has been written. If I do this on the command line
> > > then the NFS client gives the correct mtime. But this doesn't
> > > work in KMail.
> > >
> > > Conclusion: NFS sucks!!! :-(
> >
> > (silent disagreement)
>
> So you think NFS doesn't suck?

Damnit, I meant to say "(silent agreement)", oops. Sorry about that, 
yes I think NFS sucks!!!!.

> Then why does it not work as
> expected? It's been around since such a long time already that such
> problems should really have been fixed in the meantime. As this is
> not the case I have to come to the conclusion that NFS is broken by
> design.

I share your observations and conclusions. I did some mail archive 
reading and there seemed to be recent (a few years old now) work to 
fix this NFS problem but the proposed solution would result in a 
massive decrease in performance.

Basically NFS trades correctness for peformance.

> Unfortunately, I don't know of any alternatives.

I wouldn't mind doing something like requiring NFS users to start 
KMail with KMail -nfs or something.

> > > Solution for this problem: We have to store the mtime of the
> > > mbox file in the index file. This way the NFS server can't fool
> > > us and KMail.
> >
> > Well um, that can't work. That would defeat the whole purpose of
> > checking to see if the file was out of date.
> >
> > If we did that then if someone (exited KMail and) modified the
> > mbox file using an external program then the index file wouldn't
> > be regenerated. This would mean the index file would be out of
> > date and that could lead to mbox corruption.
>
> You didn't understand me correctly. What I want to do is the
> following: 1.) Write the mbox file.
> 2.) Get the mtime of the mbox file.
> 3.) Write the index file and store the mtime of the mbox file
> inside the index file.
>
> If now someone modified the mbox file then the mtime of the mbox
> file would be different from the mtime which is stored in the index
> file. This means the index file and the mbox file are out of sync
> and we have to regenerate the index file. Do I miss something?

I see what you mean now.

This is based on your observation that mbox files have the right mtime 
but index file do not, right? I'm skeptical this observation tells 
the whole story. Perhaps the mbox files had the right time because 
they were large files and took longer to write. Does your observation 
hold for small files?

> Additionally we could store the size of the mbox file in the index
> file so that we would also be able to detect modifications by mutt
> (with a very high probability). FYI, I heard that mutt does modify
> mbox files without changing the mtime.

I've verified mutt does this. But if we add code to handle this 
behavior of mutt then we should issue the previously discussed 
warning and not just handle it silently. 

Handling it silently would lure users into a false sense of security 
that everything was ok and make it much harder to track down the 
cause of lost mail if mutt unluckily deleted and inserted mails and 
didn't change the size of the mbox.

BTW: IIRC the index file format supports skipping over x bytes at the 
beginning of the file (This isn't currently used but I put in support 
for it to handle situations like this). So we shouldn't have to 
change the index file version. If the change is made correctly old 
KMail clients will be able to read the new index files with size info 
(and new KMail versions be able to read the current index files 
without size info).

Don.

_______________________________________________
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]