Import from Thunderbird

[jelabarre59]

In Epyrus (2.0.2, Linux 64bit) there's an "Import" option under the Tools menu. I figured I'd see if I could import my Thunderbird profile, but when I run the Import tool, all it says is "No application or file to import data from was found". It didn't ask for an application, it didn't ask for a location, I don't even know if this piece is working yet.

[Moonchild]

If i recall correctly that feature can import from other clients into Epyrus, not from Thunderbird (because it's effectively considered the same application in design - makes no sense to "import from itself")

[jelabarre59]

Well, Thunderbird can import from itself, unfortunately it still doesn't fix the problems I'm having there. It's even worse if I import into the "Supernova" beta since once I import an old profile into a new one (or open my old profile in the beta) all the panels turn blank; the menu and title bars are still there, & the status indicates it's checking mail so I know it's active and loads my mail, I just can't see any of it. ( https://bugzilla.mozilla.org/show_bug.cgi?id=1825374 )

I had made a profile on Epyrus for two of my IMAP accounts, and even copied over the 'offline' mail folders for those from TBird to Epyrus. A problem I'm having in TB is that in the Account Settings screens, and in the Search dialog, it says it can't find any local folders, even though they are there. Epyrus doesn't have this problem with what I've tried, so I wanted to import the entire profile to see if that could fix it, and then I could just use Epyrus instead.

Sure, I could probably let Epyrus create a new profile, copy everything from my TB profile over to that location and do a search/replace on the prefs.js file, but I think that's how I got myself into the situation the profile has now (migrating a profile both ways between Linux & MSWindows, and even on MacOS). And with a dozen or so different accounts in my profile (active IMAP accounts and archived POP and IMAP accounts) recreating a pofile from scratch will introduce plenty of errors, especially since there's no way to print out a human-readable chart of settings.

[Bilbo47]

I don't see why anyone would think TB with Supernova would be backward-compatible for profile info with previous TBs, let alone with classic mail clients like EP.
They are breaking TB for the sake of disrupting quality email usage, IMO. So mixing newest TB with classic mailers is more of a bad idea than usual.

[jelabarre59]

So I won't be able to use Epyrus to try resolving technical issues either. The intent in Supernova *IS* that it would be a direct migration path, and I have already tested two-way migration between old & new TBird (you back up your existing profile, then restore it after your test), and it doesn't break anything (further than it's already broken at least). So yes, you CAN expect it to be backwards compatible.

So I guess I'll stick with getting the TB folks to make their Export work better (they need a "Settings Exporter" that lets you pick and choose the parts you want to carry over). Maybe something that feeds the settings out to JSON.

[Navigator]

How does one transfer messages from a current version of Thunderbird to Epyrus?

[athenian200]

How does one transfer messages from a current version of Thunderbird to Epyrus?

I have no idea. I mean, it would be theoretically possible to design something that transfers messages from current versions of Thunderbird to Epyrus. But I have never really looked at what would be required for that or put any work into coding it.

It may be possible to go in the reverse direction, transferring messages from Epyrus to a newer Thunderbird, by renaming your profile directory to something Mozilla would know to look for, but currently it is probably only possible to transfer messages from Epyrus to newer Thunderbird, and not to go in the opposite direction. And even that isn't guaranteed to work.

I mean, Epyrus is a fork of older Thunderbird. It wouldn't know anything about newer Thunderbird. Unless I specifically taught it how to do that with code, and I haven't done that, unfortunately. I've definitely considered it before, though.

Well... at least no proper way. I've heard stories of people trying to just copy their profile data in and having it kind of work, but with a lot of stuff broken. So there's not really a reliable way, but I know there is a way that is generally frowned on that some people do try, but I myself don't know exactly how to do it. Someone else who uses Epyrus and has the "half-true received wisdom of the UXP Thunderbird fork users" might actually know more than me on this one.

[Moonchild]

You should be able to transfer mailbox files, or simply point Epyrus to where Thunderbird stores these files. i don't think the mailbox file format has changed.

Under Account settings, Server settings under each account, there should be a "Local folder" entry where you can see where each account mail is stored. I've had no trouble moving those file locations elsewhere and updating that Local Folder field to the new location, so you should be able to move/copy the account mail from Thunderbird folders elsewhere then point Epyrus to it.

[Bilbo47]

You should be able to ... point Epyrus to where Thunderbird stores these files.
... where each account mail is stored. I've had no trouble moving those file locations elsewhere and updating that Local Folder field to the new location

In the world of IMAP, this question does not apply, eh? The "real" instances of the messages live on the server only. Whichever client is active shows them to User, optionally storing a local copy perhaps for offline use.

Background: Even without local copies, the "mail-storage" folders hold .MSF files, which save the per-folder metadata like column order+width, message sort-order, etc.

1. I have also seen success with moving those folders out from under %AppData% and into a folder that gets backed up.

2. But Historically the folders cannot be shared / used by more than one client, nor instances of a client, nor profiles under an instance. Whenever I tried that, the running client/profile ignores the metatadata files left over by the previous client/profile and creates its own, but does not overwrite existing files. Because of naming collisions with MSF files named after the IMAP folder, we get new names like FolderThis-1.msf and FolderThat-1.msf. The [Name-1.msf] collision-count can continue a long way. The whole structure gets polluted by multiple similar yet out-of-sync representations of the folder's message-list, which is just too nuts. The fix is to exit all moz-flavor mailers, wait until IMAP connections are closed, and delete all the MSFs in the duplicate-polluted folders. Of course when you start the mailer and connect, your folder-views are back to the default layout >:( Usually at that point even restoring those folders is no help; I suppose you would have to restore the entire profile too.

So just be forewarned: as usual, back up your stuff before messing around like this

[Moonchild]

In the world of IMAP, this question does not apply, eh?

Correct. IMAP keeps all mail and folder structure on the mail server, not the local machine.
If there are "local folders" in use though, it would still apply, and it applies to pop3.

[athenian200]

In the world of IMAP, this question does not apply, eh? The "real" instances of the messages live on the server only. Whichever client is active shows them to User, optionally storing a local copy perhaps for offline use.

Off-topic:
Yeah, that's actually why I haven't thought about this question in years... all my mail is on the server, the clients I run on various computers just download it. There's not much point in migrating the existing downloaded messages to a different client when I can just login and get the messages directly from the server.

The last time I thought about this was when I needed to migrate a bunch of messages from an older version of Outlook to a newer version on a new computer. Since not long after that time, I just started using IMAP and never needed to worry about transferring downloaded messages around. They were "in the cloud" effectively.