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

List:       kde-core-devel
Subject:    Re: Corrupted kmail folders (was Re: magellan)
From:       Don Sanders <dsanders () cch ! com ! au>
Date:       1999-10-27 12:49:15
[Download RAW message or body]

> I knew/guessed part of it, but after your explanation I'm even more
> puzzled, why the folder got corrupted.
> 
> Cheers,
> Lars (using pine again for the moment :)

Do you still have the truncated folder? Is it really truncated in the middle of 
an attachment or does it end with the character sequence "\n\n" or "\n". Were 
you just reading mail at the time the truncation occurred or could kmail have 
been checking for mail say? Did kmail crash? What OS are you using?

The man page for fopen says:

Reads and writes may be intermixed on read/write streams in any order. Note 
that ANSI C requires that a file positioning function intervene between output 
and input, unless an input operation encounters end-of-file. (If this condition 
is not met, then a read is allowed to return the result of writes other than 
the most recent.) Therefore it is good practice (and indeed sometimes necessary 
under Linux) to put an fseek or fgetpos operation between write and read 
operations on such a stream. This operation may be an apparent no-op (as in 
fseek(..., 0L, SEEK_CUR) called for its synchronizing side effect. 

KMail opens mail folder files in "r+" mode for reading and writing. 

The kmfolder::addMsg(KMMessage*, int*) method contains the following snippet of 
code. 

  fseek(mStream, -2, SEEK_END);
  fread(endStr, 1, 2, mStream); // ensure separating empty line
  if (ftell(mStream) > 0 && endStr[0]!='\n') 
  {
    if (endStr[1]!='\n')
    {
      //printf ("****endStr[1]=%c\n", endStr[1]);
      fwrite("\n\n", 1, 2, mStream);
    }
    else fwrite("\n", 1, 1, mStream);
  }

I'm not sure whether technically the fread statement encounters end-of-file, it 
reaches the boundary but doesn't cross it. Perhaps something could have gone
wrong here. Yeah I know it seems extremely unlikely, and the man page just 
talks about read operations returning old data and nothing about truncating 
files. And it's only concerned with a write operation followed by a read 
operation.

I guess the fact that kmail opens the file in"r+" mode is a tiny bit dangerous,
a program with files open for writing at the time it crashes is more likely to 
corrupt them.

That's all I can think of at the moment. I checked what I said about kmail not 
writing to folder files very often, I think it's right, addMsg seems to be the 
only place such truncation could occur.

To answer you question I don't think that downloading a few thousand messages at a \
time should be a problem, I guess something to check is that kmail handles new mail \
arriving while downloading mail, were you using a local mailbox or pop?

BFN,
Don.


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