Re: [Evolution-hackers] Moving from the single mbox file format for the local folders

2009-12-17 Thread Milan Crha
On Wed, 2009-12-16 at 19:56 -0500, Jeffrey Stedfast wrote:
 Does it really crash? It used to just regenerate the summary files.

yes, on out of memory, as it tries to allocate a very large memory block
due to misreading items.

  b) you cannot just drop it and regenerate, because it holds some
  information for local providers, like labels, tags and such.

 The point of the version info was so that you could do things like:
 if (summary-version  CAMEL_64BIT_SUMMARY_VERSION) {
off_t offset;
camel_file_utils_load_off_t (file, offset);
info-offset = offset;
 } else {
camel_file_utils_load_int64 (file, info-offset);
 If you do this, then you don't actually lose any information.

I do not think the above will work together with defaulting to LARGEFILE
compile flag, but the other way would, like defaulting to load_int32 for
older summaries and reading off_t for new. I'm wondering whether some
distro has the largefile support enabled these days, as if so, then the
decision what to use as an off_t size isn't that easy. Maybe they have,
or it's enough to compile under 64 bit to have the size changed.
I didn't try this, I just suppose because of reported issues.

Evolution-hackers mailing list

Re: [Evolution-hackers] Moving from the single mbox file format for the local folders

2009-12-17 Thread Patrick Ohly
On Thu, 2009-12-17 at 17:11 +0530, chen wrote:
 So I think we can conclude the way to go as maildir. We will also have a
 preference option for sharing, which will be disabled by default for the
 local folders in evolution.

As waiters and waitresses in the US would say on such an occasion:
excellent choice, sir ;-)

Thanks for bringing this up and taking the feedback into account.

Bye, Patrick Ohly

Evolution-hackers mailing list

Re: [Evolution-hackers] Moving from the single mbox file format for the local folders

2009-12-17 Thread Jeffrey Stedfast
chenthill wrote:
 On Wed, 2009-12-16 at 09:56 -0500, Jeffrey Stedfast wrote:
 On 12/15/2009 02:46 PM, Chenthill wrote:
 Hi fellow hackers!!
 I have been working for a while during last week on one the blockers
 in evolution - -
 'Folder and summary mismatch error'(old one - As a matter of fact
 we have been working as a team to get the blockers down. I have not been
 able to reproduce the issue or yet find the exact problematic area.

 The mismatch in the frompos index in the folder summary may be caused
 by either a threading issue or a crash while storing the indexes. I am
 still investigating it to find the real cause.
 I don't think it's a threading or crash issue.
 Looking through the comments from both the bugs and the fixes that have
 gone through, i had this thought. Any other clues ?

I'd look into the situation where the user expunges a folder.  When the
mbox gets rewritten, maybe the from_offset values aren't updated or
something to reflect the new offset. That's all I can think of at the
moment. I'm sure this avenue has probably been explored before, but
maybe something got missed.

 Thinking about the amount of time this bug has been there for (primarily
 with our mbox implementation) , I thought of making some change which
 could benefit more rather than trying to just fix this. This might not
 be an ideal way to think though :)

Well, either way the bug should be fixed. Switching to Maildir is
arguably a good choice regardless, though.


Evolution-hackers mailing list