Re: [Evolution] Migration problems

[Ross Boylan <ross biostat ucsf edu>]

On Wed, 2003-08-13 at 16:47, guenther wrote:
> > Thank you for the info.  I found that simply running 
> > evolution --force-shutdown
> > and restarting was enough to get my address book back.
>
> Yep, that was the main issue to both of your questions.
>
>
> > Curiously, the only thing that didn't make the transition was the
> > calendar and task-related info.  I didn't have much there, so it's not a
> > big deal.
>
> The point is, after running Evolution once, there is a backend still
> running for calendar and tasks -- well, how will you ever expect to be
> notified about calendar entries without that? ;)
>
> You will need to --force-shutdown as well for copying calendar and
> tasks. You even can do it now, to restore the old files.
I don't quite follow this part.  I copied in the original data before
running evolution, so I don't see how this can explain the original
absence of calendar/task data.  I have since done --force-shutdown, and
still don't see the data.

How are you proposing that I restore the the calendar and contact info?

Also, it's possible the change in paths may be the source of the
problem; more about that below.

> > I have a couple of lingering concerns.  I also noticed that
> > ~/.gconf/apps/evolution/shell/default_folders/%gconf.xml includes
> > entries like
> > <entry name="mail_path" mtime="1060730873" muser="ross"
> > type="string"><stringvalue>evolution:/local/Inbox</stringvalue></entry><entry name="mail_uri" 
> > mtime="1060730873" muser="ross" 
> > type="string"><stringvalue>file:///export/home/ross/evolution/local/Inbox</stringvalue></entry>
> >
> > The "file:///export/home..." looks a little suspicious, since my old
> > machine, but not my new one, had a directory /export/home.  Is the
> > reference to /export to an actual path, or is it an internal magic word
> > for evolution?
>
> That's a current limitation. The file:// URL is hard coded to the file
> system, unfortunately. To perfectly restore old settings, you can
> substitute (find, sed) these entries wit the new ones.
>
> That said, I am not too sure, where this is being used.

This got me grepping around for the offending string, which made me
notice a few other things about the setup.  First, my on topic
questions:

I found the offending /export paths in several spots in .gconf.  I
assume I want to change those.  There were no occurrences in .gconfd,
.gnome, .gnome2, or .gnome2_private.  I also found some in evolution/.
My guess is I should change the entries in filters.xml (hmm, I wonder
what the filters do when they point to a non-existent folder).  The rest
seems to be in the bodies of messages.  I assume I can ignore this,
though I wonder if all the occurrences of
X-Evolution-Fcc: file:///export/home/ross/evolution/local/Sent
in evolution/local/Sent/mbox should be changed to assure consistency.

I assume I need to change, e.g., file:///export/home/ross/ to
file:///home/ross/ if /home/ross is my new home directory.

There is also a match in the binary file evolution/secmod.db; I'm not
sure what I can do about that or if it matters.

I assume I should make changes only after --force-shutdown.  Are there
any integrity checks built into the files (checksums, bytecounts) that
might making messing with them dangerous?

Now, off topic, I noticed copies of some of my messages, even IMAP
messages, under the evolution directory (evolution/mail/imap).  Is this
some kind of cacheing thing for performance?

I also see different directories for each IMAP server, including ones
I'm not using.  Is it safe to delete these?  And when I edited my server
name after the move (from iron.libaux.... to localhost) am I right that
doing so threw out the info for the old host name and created it anew?

> > Also, I forgot to mention in my earlier post that I was going from 64
> > bit SPARC to 32 bit Athlon, so it seemed likely that if binary
> > compatibility was an issue I would run into it (but maybe evo runs in 32
> > bit mode on Solaris, and I don't know if there are endian differences).
>
> AFAIK the only thing where littel/big endian may be an issue, is the
> berkeley database file (for Contacts) -- I am  not sure right now, but
> IIRC there was reported previously no problem while testing between
> Sparc and ix86.
>
>
> ...guenther

P.S. Do you prefer if I send mail to the list only, without a copy to you?