Evolution FAILED: Directory not empty after 2.30->2.32 (Natty) Upgrade

[iMac]

Binary package hint: evolution

After upgrading following the Beta 1 it appears my IMAP folder migration and Tasks migration from .evolution to .local was not completed entirely.

When starting evolution from the console, you can in the linked output below showing an attempt to complete the migration of folders (domains replaced w/ xx/yy and posted in another unrelated evolution bug)

https://launchpadlibrarian.net/68575182/evolution_console.txt

The main issue is the message "FAILED: Directory not empty" after "Migrating local user data" for imap and tasks folders.

After I verified that I had all the related task and imap data in .local, my workaround was to cleanup these folders in .evolution.

The tasks migrated just fine (showing up in .local and the 2.32 UI) and that folder was empty, so I just deleted it.

The IMAP accounts both had new, updated directories in .local (where they are copied to). It is not clear to me if the data was copied initially, or rebuilt during my first use from my IMAP configuration. Judging by the modification dates on the .evolution I could tell nothing had been written to these old folders since the upgrade (i.e. they were not being used). Since I use evolution heavily, and all data for these accounts is online, I simply did an rm of these folders also.

Four other SMTP only (sending only) accounts (some using the same SMTP servers) were migrated properly from .evolution into .local.

Now when I start evolution I do not see any migration errors as shown below

imac@repo:~$ evolution
Tracker-Message: Registering D-Bus service...
  Name:'org.freedesktop.Tracker1.Miner.Emails'
Tracker-Message: Registering D-Bus object...
Tracker-Message: Path:'/org/freedesktop/Tracker1/Miner/Emails'
Tracker-Message: Object Type:'TrackerEvolutionPlugin'

(evolution:7569): GLib-GObject-CRITICAL **: Object class EMFolderTree doesn't implement property 'paste-target-list' from interface 'ESelectable'

(evolution:7569): GLib-GObject-CRITICAL **: Object class EMFolderTree doesn't implement property 'copy-target-list' from interface 'ESelectable'

ProblemType: Bug
DistroRelease: Ubuntu 11.04
Package: evolution 2.32.2-0ubuntu6
ProcVersionSignature: Ubuntu 2.6.38-8.42-generic 2.6.38.2
Uname: Linux 2.6.38-8-generic x86_64
NonfreeKernelModules: fglrx
Architecture: amd64
Date: Thu Apr 14 15:16:01 2011
ProcEnviron:
 LANGUAGE=en_US:en
 LANG=en_US.utf8
 SHELL=/bin/bash
SourcePackage: evolution
UpgradeStatus: Upgraded to natty on 2011-04-06 (8 days ago)

[iMac (imac-netstatz)]

I narrowed down the scope in my upstream bug report

https://bugzilla.gnome.org/show_bug.cgi?id=648065

Quickly marked duplicate, looks like Mathieu Trudel-Lapierre already resolved this yesterday. The upstream bug includes refrence to patch is also linked.

[Mathieu Trudel-Lapierre (cyphermox)]

I don't think it's quite the same bug... This one has been fixed some time in January or February or so; so you shouldn't still be seeing empty directories such as 'task'. As for the old directories for email accounts, I'd venture this is also that something didn't quite get converted properly, even if all emails show in the directory.

Unfortunately, now we don't really have a way to figure out what went wrong seeing as the offending directories were deleted. Do you remember if they contained anything?

I'll mark this "Invalid" since we won't be able to reproduce the issue or diagnose what went wrong in the migration. Let's reopen if there's some other migration that fails or wait for another bug report about this. Sorry for the inconvenience.

[iMac (imac-netstatz)]

Well in my latest reproduction, I used data that was exported from current 2.30.3 using the in-app backup tool.. so presumably that does not create any "extra" directories that don't represent data .. but if you are saying that the backup tool backs-up garbage and other cruft lying around from really old versions of evolution, then I would agree this could be the case. If it retains only well-formed data, then I'd say the bug exists; albeit very minor.

In my case, I can reproduce this consistently restoring the backup to a fresh maverick install, and then performing the upgrade. I use PPA's to take maverick to 2.32 rather than do the "do-release-upgrade" in order to test the upgrade in less than 30 minutes.

Upstream they marked this as the same issue you corrected, but if that was already merged then I shouldn't have seen it in my Natty upgrade ten days ago.

 I bet I can remove ALL my email, contacts, memos and calendars, and do an export of my configuration that would not contain any sensitive data, effectively making it easy for anyone to reproduce - let me know if that would help, as it is probably easy to do in about 30 minutes; (revert snapshot, import full backup data, clean-up, re-backup in 2.30.3, review, upload).

[Mathieu Trudel-Lapierre (cyphermox)]

Yes. If you can show a case where there is no sensitive data and the upgrade fails, then it's definitely helpful to have a copy of that data to figure out what doesn't get migrated properly. I'd expect it's because of some old config from previous versions though.

Also, note that using a PPA for the upgrade might not be the best: if it's the packages for 2.32 on Maverick I uploaded to my PPA some time ago I'm not sure if they contained the patches to properly transition and remove the empty directories ;)

[iMac (imac-netstatz)]

Regarding PPA use, I agree. The original bug was from my 11.04 update (as apport shows). Reproduction using the PPA simply demonstrated to me it is likely a consistent behaviour. Additionallly I wanted to see it on a clean install to rule out other cruft and didn't care to go through a many hours upgrade to execute a single test scenario.

My assumption was that this is legacy data. I'll go ahead an create the evolutionbackup.tar.gz and test that it results in the desired scenario, however I have no task data (maybe forgot to mention that) - I don't even recall trying this feature out, so I was surprised to see some structure there. Perhaps it is actually the lack of data combined with some previous migration in an earlier version of evolution that causes this extra directory.

[iMac (imac-netstatz)]

I had a look at the dates on the file structures, and decided that this is definitely legacy migration issue that can probably be left alone.

imac@n8-laptop:~/.evolution/tasks/tasks$ ls -al
total 12
drwx------ 3 imac imac 4096 2008-12-23 11:03 .
drwx------ 3 imac imac 4096 2011-04-10 11:48 ..
drwx------ 2 imac imac 4096 2008-12-23 11:03 views

Probably a 2.22 or 2.24 upgrade that created this directory by my guess, and it might have been migrated from an earlier configuration, going right back to pre-1.0 ximian.

[Mathieu Trudel-Lapierre (cyphermox)]

I think we can safely mark this "Won't Fix"; and reopen/revisit the issue if there are further reports of issues with migrating files.

[Kevin Turner (keturn)]

I've been getting this error (on the mail/imap directories, not tasks). I don't have time to scrub sensitive data from my mail directories for submission to a public bug tracker this morning, but maybe can get to that sometime in the next week.