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. [EMAIL PROTECTED] - www.ximian.com
