Re: [Evolution] Evo mail: explanation of old and new file system

["carpetnailz researchintegration org" <carpetnailz researchintegration org>]

As nearly as I can reconstruct, here's what happened:

-I was running Ubuntu 10.04 with Evo 2.28.3. 
-Last September (2011) I moved to a new computer and tried to run Ubuntu
11.04, giving up after about two weeks because I could never get the
screen to work right. So I backed all my home directory stuff and wiped
the drive and went to Fedora 15.
-It took me a while to get Fedora 15 straightened away because of EFI
issues, as I recall.
-When I copied the .evolution folder, it did not have any of my emails
or calendar entries from the two weeks I was trying to use Ubuntu 11.04.
Apparently with Ubuntu 11.04 Evolution had started to use the new
location, but there was no indication of this anywhere. Efforts to find
out what was happening were hampered by a red herring about a possible
bug in the backup tool.
-Eventually things seemed to sort out, but exactly what I did back then
is foggy.
-Apparently not everything got copied over, because now I see that
several of my old folders are empty. That's what occasioned this thread.

So this is why I need to have an explanation of the file structure and
file types: when I look in
   /home/eric/.local/share/evolution/mail/local/  
I see a strange mixture of the "old" mbox type files and,
under /home/eric/.local/share/evolution/mail/local/cur, a zillion
entries that look like
'1339022703.13737_7755.localhost.localdomain:2,ST'.

This is all very confusing. I want to know what's happening and how I
should go about moving the missing mail from my old backups to the new
situation. What are these
   '1339022703.13737_7755.localhost.localdomain:2,ST' 
files? How do they relate to the mbox-type files? Do I just copy the
missing mbox files to the new location and just let Evo do the
conversion? Do I need to copy all six of the old .evolution files for
each of the mailbox folders (that is, the sample set I listed in my
initial email in this thread)?

As I asked there: 

"So assuming I can find those old emails in ~/.evolution on one of my
old backups, what's the procedure for moving them to the new format? Do
I just copy everything from the old to the new?  E.g.
    .evolution/mail/local/xLynnOld
    .evolution/mail/local/xLynnOld.cmeta
    .evolution/mail/local/xLynnOld.ibex.index
    .evolution/mail/local/xLynnOld.ev-summary
    .evolution/mail/local/xLynnOld.ev-summary-meta
    .evolution/mail/local/xLynnOld.ibex.index.data
to
    .local/share/evolution/mail/local/.xLynnOld
?"

It's all well and good to say, "There isn't in the user docs because
it's nothing that a user should need to care about. It should be all
automatically."  But the user does need to care about it since he has to
fix the problem. And he has to understand what's happening.

Thanks.


On Wed, 2012-06-06 at 11:19 +0200, Andre Klapper wrote:
> On Tue, 2012-06-05 at 14:35 -0400, carpetnailz researchintegration org
> wrote:
> > I'm still not clear about the relation between the old file system and
> > storage location and the new. And there doesn't seem to be any
> > explanation of it in the user documentation for Evolution mail.
>
> There isn't in the user docs because it's nothing that a user should
> need to care about. It should be all automatically. Unfortunately there
> are sometimes bugs or users who try weird stuff. :P
>
> > For example, tho I thought I had successfully imported all the old mail,
>
> From which version to which version? By using "File > Restore Evolution
> Data..." or how?
>
> > Where can I find an explanation in lay terms of what the changes were
> > and how one deals with them? It seems that suddenly Evolution started
> > doing things differently and users were left to figure things out on
> > their own.
>
> The upgrade from 2.32 to 3.2 worked pretty well for me (about seven
> months ago), except for three or four smaller bugs.
>
> > Maybe this is explained somewhere and I just haven't found it? Again, it
> > would be good if this were in the user documentation
>
> It would be better if bugs get fixed instead, especially as changes to
> the user docs would target version 3.6. I don't care about updating 3.2
> or 3.0 documentation anymore (they would not even be deployed on the
> server as nobody plans to do new releases for such old versions).
>
> andre