Re: serious bug. Evolution and Microsoft mentality.
On Wed, 2002-01-09 at 01:43, Jonathan Walther wrote:
> On Mon, Jan 07, 2002 at 01:56:24PM -0500, Jeffrey Stedfast wrote:
> >Yea, this is kinda painful currently but hopefully by 1.2 this will be
> >much easier. We plan on making it so that you can add a new account
> >using "Standard Unix Mail Spool" as the source type and pointing it at a
> >directory and have our code automatically show all the mailboxes in the
> >directory. Currently it will only accept single mbox files as sources.
>
> That will be very nice. Will you also let us point to Maildir's and
> have it Just Work? Maildir format allows us to continue using procmail
> and related programs without worrying about locking issues between
> Evolution and outside mail delivery programs and filters.
Actually, Evolution already supports pointing to outside Maildir
directories ;-)
>
> >It's not really a good idea to use symlinks because Evolution will lock
> >the symlink file and if you have procmail running, it will lock the real
> >mbox file and so if you try and access the same mbox file with both
> >Evolution and procmail, things will end badly for you (ie corrupt
> >mailbox).
>
> Correct. Thats why I plan to switch over completely to Maildir format.
>
> >> What happened? My symlink was erased! Gone! A new mbox file had been
> >> created from the contents of the original.
> >
> >Did you delete/expunge messages? I presume that you must have because
> >otherwise the mbox would not have been rewritten. The only way to remove
>
> Unfortunately, no. I made no changes whatsoever to the mailboxes. I
> just entered them to see if the messages showed up, they did, then I
> exited. Thats when I noticed the symlinks had been blown away, and the
> resulting "copied" mailbox was bigger in size than the original!
Ah, I bet I know why... Evolution added an X-Evolution header to each
message for status purposes. The X-Evolution header contains an encoded
UID and message flags. That would also explain why it got bigger than
the original file.
>
> >messages from an mbox file is to rewrite it to a new tmp file (minus the
> >messages to be deleted) and then rename that tmp file back to its
> >original name. Unfortunately, UNIX's rename() function clobbers symlinks
> >and thus your problem.
>
> Well, alright. I did some research tonight. Before calling "rename()",
> a call to realpath() would resolve the symlink to the correct "real"
> filename, and using that would give the correct result. An extra 3
> lines of code (to find out how much storage is needed for the real path,
> to allocate it, then finally to call realpath()).
Actually, this isn't guaranteed to work :-(
rename() is unfortunately limited to renaming files on the same file
system, once you add symlinks to the equation - you could be leaping
across file system boundaries and there isn't a way to tell (well, ok,
so you can check st.st_dev and compare the 2).
The only way I can think of to get around this is to create the tmp mbox
file in the same directory as the original (after being realpath()'d).
This may also have problems - what if you don't have write-permission in
that directory?
>
> >Actually, Evolution plays very nice with other mail software on the
> >system - you just have to not use symlinks.
>
> Supporting symlinks is easy. Not supporting them is un-Unixy.
Not as easy as you seem to think, you missed that rename doesn't work
across file systems ;-)
Anyways, I'll look into it...
>
> >Evolution locks all
> >mailboxes when it goes to access them to avoid mailbox corruption and so
> >as long as the other system mail software does the same (which it
> >should) then they will all live in harmony.
>
> Again, provided one uses Maildir mailboxes, things will be fine. But
> the thought occurs, Evolution should do its "locking" on the file
> returned from realpath() too.
You are probably right.
--
Jeffrey Stedfast
Evolution Hacker - Ximian, Inc.
fejj@ximian.com - www.ximian.com
Reply to: