Attached is the file notes containing my notes about the migration of
Evolution data from 2.24.5 to 3.4.3.
The basics of this file is the procedure to migrate data (not a complete
configuration) from 2.24.5 to 3.4.3.
The data can be merged into already existing data running under 3.4.3.
The scenario I was under was;
1. I had an older system running Fedora 10 Evolution 2.24.5 that had an
apparent hardware failure.
2. A new laptop running Fedora 15 with Evolution 3.4.3
3. I already had the new systems email up and runnning.
4. I was not using calender or other features of the Evolution on the
old system.
I hope this helps others so afflicted.
I would like to thank those that contributed information to my search
for a solution.
This file is a set of notes about how I solved a problem migrating from an
older machine running Fedora 10 with Evolution 2.24.5 to Fedora 15 Evolution
3.4.3.
My older machine was dying a hardware death and I considered it unable to be
updated or changed in any way.
My new machine had arrived and I got connected to my ISP server using Evolution
3.4.3. So it went from a simple migration into a merge.
I had mail already present that 3.4.3 new about and mail that was valued from
the old machine.
While the old machine was working I got Evolution 2.24.5 to perform a backup
into a local file evolution-backup.tar.gz
That file was moved to the new machine using one of those USB flash drives.
What follows is a procedure/dialog about how to get various message folders
from the backup of the old 2.24.5 data into the area of the new 3.4.3 system.
================================================================
First some symbols I used
OLDEVOL=$HOME/mytest/old/.evolution/mail/local
NEWEVOL=$HOME/.local/share/evolution/mail/local
TMPEVOL=$HOME/mytest/new
Place that backup file in your home dir from my flash drive
$HOME/evolution-backup.tar.gz
So as to reduce vulnerability I did a backup of 3.4.3 and set it aside.
Then I worked in a temporary directory called mytest
This area would hold both the backup from the old system and converted folders
prior to populating the new evolution tree.
mkdir $HOME/mytest
cd $HOME/mytest
mkdir new old
I placed the old mailbox system into old
cd $HOME/mytest/old
tar xvf $HOME/evolution-backup.tar.gz
A quick view of the resulting directory was disappointing at first but I
realized that the data was really visible at $OLDEVOL
Each working folder for our example OURFolder under the old system was visible
as four files
OURFolder
OURFolder.cmeta
OURFolder.ibex.index
OURFolder.ibex.index.data
The actual email messages were found in OURFolder.
As this procedure deals with selective restoration of a folder from the old to
the new we will use the name OURFolder.
This is the name it would have appeared as under Evolution 2.24.5.
And ultimately under 3.4.3.
We are going to build a temporary copy of the mail messages in our mytest
directory tree.
$HOME/mytest/new
I used a perl script I found on the internet.
The file was mb2md-3.20.pl
It came from batleth.sapientia-sat.org/projects/mb2md
It needs to have a TimeDate Perl library loaded.
I installed a package using RPM.
Sorry, but I cannot remember where I found it.
I found it using google looking for Perl TimeDate
The original mail mbx file is located by
$OLDEVOL/OURFolder
The new directory in our working Evolution 3.4.3 will be located by
$NEWEVOL/.OURFolder/cur
Note the . before OURFolder
The conversion will go from a single file $OLDEVOL/OURFolder to a directory
$NEWEVOL/.OURFOLDER/cur that contains files each with a separate email message.
We will place the files in a temporary dir $HOME/mytest/new
my nomenclature for this is TMPEVOL
perl mb2md-3.20.pl -s $OLDEVOL/OURFolder -d $TMPEVOL/OURFolder
The script will kick out some complaints but will do all the messages.
No here is a find point to examine. The script uses a procedure to convert. I
found it worked for my mail from my ISP.
There is a option in the script to do the conversion a bit differently. So it
may be necessary to read some of the messages and see if they make sense. Not
really likely unless one speaks email header gibberish.
take a look at $TMPEVOL/OURFolder/cur
There will be many files. One per email message encountered by the conversion
perl program.
If it looks good. Now remember it is the raw message.
evolution will change its appearance.
NOW THE MOST IMPORTANT PART
enter evolution
create a new folder OURFolder
Shut evolution down.
copy the files from our temp directory to the 3.4.3 directory
cp $TMPEVOL/OURFolder/cur/* $NEWEVOL/.OURFolder/cur
note the . infront of the OURFolder in the destination directory
This means you must get used to using the -a option in ls to see these
folder/directories as you work with them.
NEXT IMPORTANT PART
enter evolution
select OURFolder (the name we used)
sit and wait
select inbox
select OURFolder
the converted mail messages should be there now.
Some of this ritual of flipping between OURFolder and inbox may not be
necessary but it is how I saw it.
This is the time that you get to see if the conversion performed makes real
sense. View the messages carefully and if you like it keep them. They are
yours.
Then you get to repeat the process for each of the folders from the old system
you want to restore to the new system.
I chose this way as I was going to perform a merge.
In some cases I had folders on both old and new that had the same name. So how
I chose to handle that is to take OURFolder and make a Old_OURFolder on the new
system. Then using Evolution in a normal way I could move mail messages I
wanted to keep from the Old_OURFolder to OURFolder and eventually delete the
Old_OURFolder.
That is the end of the procedure.
<Begin editorial mode>
The key things that I learned here are;
1. the two different versions of Evolution had two different mailbox styles.
2. The two versions of Evolution were not compatible.
3. the evolution of Evolution had abandoned those with older systems.
Cynical but apparently true.
Backwards compatibility is very important.
The useful migration of data is not as simple as constantly updating your
mailsystem as each version comes out.
Some versions may not offer a real reason to migrate.
I for one don't want to become a slave to updates like Windows users are a
slave to updates.
Rather I look at my Linux environment the same way I looked at HP-UX as a
stable working environment that changed when we had to. Not just as HP came
out with new versions. When our old machines became HP Obsolete then we were
forced to move.
<End editorial mode>
_______________________________________________
evolution-list mailing list
evolution-list@gnome.org
To change your list options or unsubscribe, visit ...
https://mail.gnome.org/mailman/listinfo/evolution-list
