SeaMonkey 2.32 - Copy entire profile no longer works

[barbaz]

Upgraded to SeaMonkey 2.32, and discovered that now copying an entire profile from one machine (Mac OS X) to another (Linux) results in all extensions being disabled or removed.
Starting SeaMonkey from a Terminal, I get messages indicating that the issue is mostly the absolute path of the profile being different, but one XPI - which works fine on the Mac - was corrupted.
(This wasn't a problem before, and none of my XPIs used to get corrupted.)

Fixing the paths in extensions.ini, and deleting extensions.json and extensions.sqlite, got all the non-bootstrapped extensions working right away, but they were then installed in the wrong order (yes, that matters in my profile); this still didn't take care of the bootstrapped addons referenced by absolute path in prefs.js.
Leaving the extensions.json/extensions.sqlite alone, it just said there was an error parsing it, and same result otherwise.

This is an enormous problem for me because I was relying on being able to copy entire profile and have it "just work" to maintain the SeaMonkey installs in my VMs. There are just too many customizations in my profile for me to fix things that don't work from within SeaMonkey, especially given that there are several VMs involved here.

Short of downgrading SeaMonkey on my Mac (the "master" copy of the profile), which isn't a good answer, is there a way around this? If not, is there an automated tool to migrate an entire profile from one machine to another?
If no automated tool exists, what would an automated tool have to do to fix the profile so that things "just work" after copying entire profile and running the tool?


ETA Found a copy of my Mac profile from before I upgraded, and copying that profile (from SeaMonkey '2.28esr') directly to SM 2.32 on Linux doesn't have this effect. Is there something I can take advantage of in that, to make copying entire profile work again?

[DanRaisch]

Moving to Sea Monkey Support.

[barbaz]

Was going to file a bug per advice on IRC, but it's working today... no idea what I'm doing different from yesterday when it failed repeatedly as described in the OP
sorry to waste your time

[DanRaisch]

No problem. Glad to hear it's working again.

[therube]

one XPI - which works fine on the Mac - was corrupted

Why should an XPI corrupt on a copy?

Found a copy of my Mac profile from before I upgraded, and copying that profile (from SeaMonkey '2.28esr') directly to SM 2.32 on Linux doesn't have this effect.

Why should there be a difference just because the Profile originated from different SeaMonkey versions?

Was going to file a bug per advice on IRC, but it's working today

So what changed? (& I ask that as I'm playing Sheryl Crow's "A change will do you good" .)

Any material differences between an ESR Profile & an "upgraded" copy?
As in did the Profile files (including their contents) change, or only the Profile path where they're newly stored?
Any (material) changes in the Profile files between the ESR & the new?
You've mentioned extensions.ini. And it was brought up before that some Mail paths may be absolute.

[barbaz]

one XPI - which works fine on the Mac - was corrupted

Why should an XPI corrupt on a copy?

No idea, but:
1) the XPI really was corrupted, Archive Manager couldn't open it (and it did indeed get changed from the original)
2) that issue must have been on the destination end - it worked even with the exact same source, which was a copy of my profile I made yesterday that had just sat where it was, untouched except to make copies of it, between 'not working' and 'working'.

Why should there be a difference just because the Profile originated from different SeaMonkey versions?

I would have guessed something to do with SeaMonkey 2.32 changing the way extensions were handled and the new system not being compatible with absolute paths changing when SeaMonkey is shut down, but the fact it worked today (on 3 different Linux machines) indicates otherwise.

(& I ask that as I'm playing Sheryl Crow's "A change will do you good" .)

Any material differences between an ESR Profile & an "upgraded" copy?
As in did the Profile files (including their contents) change, or only the Profile path where they're newly stored?
Any (material) changes in the Profile files between the ESR & the new?

Well, I know for sure the prefs.js would have changed (for example, extensions.installCache is gone, and the appversion / platformversion prefs changed), and I don't think I had an 'xulstore.json' before the upgrade. I'll try to do a diff of current profile and latest backup I've got tomorrow, but I've probably changed other things at this point and I just upgraded *all* my SM browser installs to 2.32 and deleted all local copies of my ESR profile...

And it was brought up before that some Mail paths may be absolute.

AFAIK (and based on comments patrickjdempsey has made) they are, but I don't use Mail in this profile. I wouldn't want to migrate my Mail profile to multiple machines for active use...

[patrickjdempsey]

In my profile in Windows, there are absolute paths in (at least):

compatibility.ini
extensions.ini
extensions.json
extensions.log
mimeTypes.rdf
panacea.dat
pluginreg.dat
prefs.js
search.json

I was unable to check any of the sqlite or db files but I'm betting there are a few in some of those as well. It's amazing to me that this works for you at all.

[therube]

content-prefs.js has, I suppose it is, download directory stored (or something, seemingly immaterial, like that)
downloads.sqlite likewise must store an "opened" files "application", like path to an external pdf reader
places.sqlite, not seeing anything there
pluginreg.dat has something like C:/Profile/plugins/xyz.DLL
secmod.dat has a dconfigdir= variable that looks to point to your Profile location [possibly no longer used?]
webappsstore.sqlite, probably ought to be banished outright

The only things I'm seeing that potentially would be of concern are the extension related files & hardcoded paths in prefs.js (user.js).

[barbaz]

Done some diffs, and there's just too much personal information in there for me to post any of it, sorry.
The only real difference I noticed was extensions.ini had a [MultiprocessIncompatibleExtensions] section which seemed to list all the non-bootstrapped addons...
EDIT oh, bootstrapped addons weren't even listed in either extensions.ini.

In my profile in Windows, there are absolute paths in (at least):

compatibility.ini
extensions.ini
extensions.json
extensions.log
mimeTypes.rdf
panacea.dat
pluginreg.dat
prefs.js
search.json

Did a diff of profile before migration and profile in my VM snapshot (after migration and running SeaMonkey once) to see what it did.
compatibility,ini, extensions.ini, extensions.json, prefs.js, and search.json had the necessary absolute paths adjusted (note: all those but compatibility.ini contain some sort of indicators whether the paths are in the profile directory, and compatibility.ini paths that I have seem to all point to the app install directory).
compatiblity.ini in the VM snapshot contained the extra line "InvalidateCaches=1" which disappeared after running SM again.

my mimeTypes.rdf has no absolute paths...

pluginreg.dat was rebuilt for the new system.

I don't have a panacea.dat or extensions.log in my profile...

I was unable to check any of the sqlite or db files but I'm betting there are a few in some of those as well.

The only sqlite file that changed after migration was places.sqlite...
Of all the sqlite files, the only one with absolute paths was extensions.sqlite which I think is obsolete?
I don't know what a db file is so I can't check that, but I'd guess there's no absolute paths there.

[patrickjdempsey]

Bootstrapped extensions are listed in prefs.js with full paths.

mimeTypes.rdf lists your helper programs. If you end up setting up a helper program that isn't the OS-associated one for that type, then you'll end up with an absolute path to that application.

[barbaz]

Bootstrapped extensions are listed in prefs.js with full paths.

Which were adjusted for the new profile...

On second look, I actually don't see anything in the extensions.bootstrappedAddons pref that says "in the profile folder"...

mimeTypes.rdf lists your helper programs. If you end up setting up a helper program that isn't the OS-associated one for that type, then you'll end up with an absolute path to that application.

Yeah, that's definitely not something I'd expect to transfer between different OSes and have it automagically figure what the new paths should be.
I always 'save file' when SeaMonkey can't handle something itself, so that explains the lack of absolute paths in my mimeTypes.rdf.
I try to keep my profile as self contained as possible so that there aren't many loose / invalid absolute paths after copying to another system and running SeaMonkey there, and the loose absolute paths that are left (e.g. Scriptish editor preference) aren't anything I'd run into much and are easy to reset for the new system as I need them.