Open Bug 950584 Opened 11 years ago Updated 2 years ago

Profile should avoid absolute paths when not necessary

Categories

(Thunderbird :: Preferences, defect)

Product:
Thunderbird
Component:
Preferences
Version:
24 Branch
Platform:
x86_64
FreeBSD
Type:
defect

Tracking

(Not tracked)

Status:
UNCONFIRMED

People

(Reporter: yuri, Unassigned)

References

(Blocks 1 open bug)

Details

User Agent: Mozilla/5.0 (X11; FreeBSD amd64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/31.0.1650.57 Safari/537.36

Steps to reproduce:

I moved the ~/.thunderbird folder to the new machine under different user name.


Actual results:

Thunderbird on the new machine didn't pick the profile up because profile under ~/.thunderbird contains absolute paths from the old OS. I had to manually correct absolute paths in two files: prefs.js and panacea.dat. Many paths there were under ~/.thunderbird, and others under user's home directory.

Proposed solution:
Thunderbird should avoid storing absolute paths in profile. Instead, it should have some special notation for the ~/.thunderbird and home folder, for example like this:
user_pref("mail.root.imap", "$TB/5xzurega.default/ImapMail");
user_pref("messenger.save.dir", "$HOME/Desktop");

Only when user selects locations not under the home directory, thunderbird should store absolute paths in the profile.
For mail directory, mail.server.server#.directory-rel=[ProfD]Mail/x.y.z and mail.root.*-rel=[ProfD]Mail is already used. mail.server.server1#.directory and mail.root.* is set from .directory-rel and .*-rel, and is for backward compatibility purpose only.
And, profile directory can be defined as "relative from directory Tb owns".
 profiles.ini
  [Profile0]
   Name=Test
   IsRelative=1
   Path=Profiles/ueihzgrp.Test

> I had to manually correct absolute paths in two files: prefs.js and panacea.dat.

Because mail.server.server#.directory-rel and mail.root.*-rel is used, there is no need to manually modify prefs.js after "profile copy", as far as "depth of Tb's profile directory is not changed by profile directory copy" or "mail directory is placed under Tb's profile directory.

Manual modification of server.server#.directory-rel/server.server1#.directory is needed only when both of next occurs; 
 - depth of Tb's profile directory is changed by profile directory copy
 - mail directory is not placed under Tb's profile directory(placed outside of profile).
This is because "replative path from copied profile" != "replative path from original  profile" happens by the profile copy.
This is never "problem due to absolute path".
If server.server1#.directory contains requred path, "delete .directory-rel" is simplest way.

Path saved in panacea.dat is still absolute path(extensions.ini is another absolute path example).
However, after profile copy, mail folder/mail file is automatically searched using mail.server.server1#.directory-rel.
There is no need to change panacea.dat content for mail directory path, even if absolute path is used in panacea.dat file. As for "absolute path in panacea.dat for mail folder file", "profile copy" is merely same as "delete of panacea.dat file". 

Where was profile location on old machine?
Where is new profile location on new machine?
Which entry should be manually modified upon your migration to new machine?

> user_pref("mail.root.imap", "$TB/5xzurega.default/ImapMail");
There is usually no need to set it, because any directory can be selected at "Local Directory:" of "Server Settings".
Does it mean that you use "mail directory located outside of profile" for mail/news account and that you alter mail.root.imap-rel/mail.root.imap?

> user_pref("messenger.save.dir", "$HOME/Desktop");
IIRC, [HomeD]/ABC/DEF like notation is requested by other bug for user's convenience in profile migration, although I'm not sure.
(In reply to Yuri from comment #0)
> Actual results:
> Thunderbird on the new machine didn't pick the profile up because profile
> under ~/.thunderbird contains absolute paths from the old OS. I had to
> manually correct absolute paths in two files: prefs.js and panacea.dat. Many
> paths there were under ~/.thunderbird, and others under user's home
> directory.
You seem to mix the profile with the locations of the mail data (Local directory pref of each account). So please clarify.

> Proposed solution:
> Thunderbird should avoid storing absolute paths in profile. Instead, it
> should have some special notation for the ~/.thunderbird and home folder,
> for example like this:
> user_pref("mail.root.imap", "$TB/5xzurega.default/ImapMail");
This is already done, in the user_pref("mail.root.imap-rel", "[ProfD]ImapMail");
Your "$TB" is encoded as "[ProfD]".

Anyway, the mail.root.* prefs are not used for existing accounts. For those, the prefs "mail.server.server*.directory" and "mail.server.server*.directory-rel" are used. Of those, the -rel (relative) version takes precedence if found, as WADA describes.

And if you are moving the profile (settings) to a new machine/user, you need to manually craft the file profiles.ini so that TB can find the copied profile (.thunderbird/xxxxxxx*), otherwise it creates a new random one (.thunderbird/yyyyyyy*).
(In reply to :aceman from comment #2)

> You seem to mix the profile with the locations of the mail data (Local
> directory pref of each account). So please clarify.

I meant both of them.

> > Proposed solution:
> > Thunderbird should avoid storing absolute paths in profile. Instead, it
> > should have some special notation for the ~/.thunderbird and home folder,
> > for example like this:
> > user_pref("mail.root.imap", "$TB/5xzurega.default/ImapMail");
> This is already done, in the user_pref("mail.root.imap-rel",
> "[ProfD]ImapMail");
> Your "$TB" is encoded as "[ProfD]".

No, I just copied ~/.thunderbird from fully updated FreeBSD to Linux under different user name and had this issue with profile/folders locations.

> And if you are moving the profile (settings) to a new machine/user, you need
> to manually craft the file profiles.ini so that TB can find the copied
> profile (.thunderbird/xxxxxxx*), otherwise it creates a new random one
> (.thunderbird/yyyyyyy*).

This is exactly what I am trying to prevent with my suggestion. Most users (as a default) have all info located under ~/.thunderbird, and moving such folder should be as simple as, well, just moving it. There is really no reason for this to be more complex in a default case. 

Yuri
Ah, actually ~/.thunderbird contains profile.ini so it should work just copying the whole directory. Unless profile.ini contains absolute paths.

So I still do not understand what was not picked up. Or how did you determine the profile was not picked up.
(In reply to :aceman from comment #4)
> Ah, actually ~/.thunderbird contains profile.ini so it should work just
> copying the whole directory. Unless profile.ini contains absolute paths.
> 
> So I still do not understand what was not picked up. Or how did you
> determine the profile was not picked up.

File ~/.thunderbird/qasr4gn7.default/prefs.js, for example, has many lines like this:
user_pref("mail.root.imap", "/home/yuri/.thunderbird/qasr4gn7.default/ImapMail");
Same with panacea.dat.
There is [ProfD] tag in some lines, but not in some other lines. Not in "mail.root.imap"
Yes it does sometimes. How does it affect you? Is there "mail.root.imap-rel" pref? If yes, it takes precedence as already said. You can remove the absolute "mail.root.imap" pref, I think it even will not be recreated (it is not in my profile).
(In reply to :aceman from comment #7)
> Yes it does sometimes. How does it affect you? Is there "mail.root.imap-rel"
> pref? If yes, it takes precedence as already said. You can remove the
> absolute "mail.root.imap" pref, I think it even will not be recreated (it is
> not in my profile).

Lines like this caused non-portability of ~/.thunderbird folder. Not sure which ones exactly, but why not all of them are replaced with [ProfD]?
Why you repeatedly refer only mail.root.imap, even though we repeatedly say "mail.root.imap-rel is used by Tb"?
Why you repeatedly say "mail.root.imap is cause of non-portability" even though I said "it's entry for absolute path, for downward compatibility"?

See prefs setting via Config Editor, with filter="mail.root." (Tools/Options/Advanced/General in Win)
No mail.root.*-rel entry? (* : none, pop3, imap, nntp)

If no mail.root.*-rel entry, when was the mail.root.imap entry generated in your prefs.js by whom?
By pretty old Thunderbird which didn't support mail.root.*-rel even though you never touched mail.root.*-rel nor mail.root.* in prefs.js file?

> but why not all of them are replaced with [ProfD]?
It's prety simple in .*-rel/.*, .directory-rel/.directory.
  Entry for absolute path is written in absolute path.
  Entry for relative path is written in relative path.
For file path in panacea.dat and extensions.ini.
  It's not written in relative path yet. It's still written in absolute path.

> Most users (as a default) have all info located under ~/.thunderbird,
> and moving such folder should be as simple as, well, just moving it.
As I already stated, as for mail directory, folloqwing is already possible,
 1.　Just copy Tb's profile directory to other location including new machine.
 2. Register it in profiles.ini
    "Ceeate Profile" of profile manager, specify profile name,
    then choose the copied directory as Tb's profile directory for this new profile.
except in special situation.
Why such simple and pretty easy job is so hard in your environment?
Why non-portability of some kind of data, such as "last used directory is absolute path", is so critical problem in your environment?

You refer imap. Following happened?
- After migration to new machine, upon first restart of Tb, imap server access failed.
- Because of absolute path in panace.dat and imap server access failure,
  relation between mbox name and file name is lost.
- So, all mail is re-fetched and auo-sync'ed again,
  or "view mails in imap folder with Work Offline mode at new machine" is impossile
  untill you correcly setup network environment at new machine.
(In reply to WADA from comment #9)
> Why you repeatedly refer only mail.root.imap, even though we repeatedly say
> "mail.root.imap-rel is used by Tb"?
> Why you repeatedly say "mail.root.imap is cause of non-portability" even
> though I said "it's entry for absolute path, for downward compatibility"?

Sorry, you misunderstood me. I only provided this one as an example. I am not saying this line is a cause.
*Some* entry like this causes non-portability.

My point is this: all paths should be checked for being under ~/.thunderbird/ and, next, under ~/. If they are (as in a default install), tags "[ProfD]", etc should be added there and absolute paths should be eliminated.
Currently you only treat some entries in this or similar way, and I suggest you do this for all paths.

This way default profile will be completely portable.
(In reply to Yuri from comment #10)
> *Some* entry like this causes non-portability.
You still don't look to understand what aceman: and some other peoples said.
  mail.root.imap is entry to save absolute path version of mail.root.imap-rel
  which current Tb uses. mail.root.imap is for Tb who didn't support mail.root.imap-rel.
  Even though it, you repeatedly say "mail.root.imap should be relative".
As far as mail.root.imap is contained in your *Some entry like this which causes non-portablity", your claim can not be proper, even if valid "absolute path in panacea.dat is a cause of problem during migration" is involved in your claim.

And, you don't understand about following.
  Even if relative path is correctly used by mail.server.server#.directory-rel,
  if user copied profile directory to different level of directory hierarchy,
  relative path of directory /OutSideOfProfile/Dir/SubDir in copied profile
  is different from
  relative path of directory /OutSideOfProfile/Dir/SubDir in original profile.
  "Copy of profile directory" is done by user at outside of Tb.
  Tb can't know where is user's intention on directory location,
  once Tb's profile directory is copied by user.
  Currently, Tb uses mail.server.server#.directory if mail.server.server#.directory-rel
  doesn't exist, Tand b generates mail.server.server#.directory-rel from existent
  mail.server.server#.directory(==absolute path in original profile is still held, if
  and only if "just after directory copy").
  So, "delete mail.server.server#.directory-rel just after profile copy"
  is currently simplest && easiest way to request /OutSideOfProfile/Dir/SubDir to Tb,
  if "just after profile copy" and "before first use of the copied profile".
This is never "problem due to absolute path in Tb/Tb's profile".
This is rather "problem due to relative path".
[AbsPath]/OutSideOfProfile/Dir/SubDir like notation, which is similar to [HomeD]Desktop like notation you are requesting, may be needed for this kind of issue.
This kind of issue may be worked around by symbolic link use, but symbolic link may produce much critical problems in Tb... :-) 
  
Problem due to "absolute path for mail folder file in panacea.dat" is already known.
From perspective of "path for mail folder file", "profile copy" is identical to "delete panacea.dat file", because path saved in panacea.dat is absolute path.
(a) So, directory scan for all mail.server.server#.directory-rel and his *.sbd subdirectories is needed. This takes long if many mail folders are used, because "directory scan by OS" usually takes long, and it takes longer if "file share" is used for mail folder file.
(b) So, if IMAP, and if "first normal access to IMAP server after profile copy" is impossible, relation between "mbox name at server and local file name used by Tb" is lost.
  - such data can't be obtained from panacea.dat.
  - mbox name at server can't be obtained from IMAP server.
This "absolute path in panacea.dat" produces same problem in "profile share by multiple machine(use alternatively)" if drive letter in Win for remote directory is different.
    Profile directory is pointed by profiles.ini on each machine.
    So, same profile directory held on file share server can be shared pretty easily.
(c) However, if drive letter on Win is different, non-portability of panacea.dat is
    exposed to user, if many mail folders are used.
    IIUC, "Portable Thunderbird" doesn't resolve this kind problem.

Problem due to "absolute path in extensions.ini" is also already known.
However, even if "pointer to extension's file in extension.ini" is lost by "profile copy", extension(add-on) is normally initialized by enhancements/improvements around add-on in Tb. So, "problem due to absolute path in extensions.ini" can not be observed in ordinal environment".

Yuri : 
What absolute path in what prefs.js entry or what file actually caused non-portability problem in your environment?
Merely "You saw absolute path in panacea.dat and mail.root.imap, so you are claiming relative path should be used by Tb"?

Please surely exclude already known panacea.dat/extensions.ini, mail.root.*-rel/mail.root.*, mail.server.server#.directory-rel/mail.server.server#.directory relevant issues.
Please surely exclude already known mail.root.*-rel, mail.server.server#.directory-rel relevant issues which is caused by "relative path use".

Please note that [HomeD] like notation should be effective in profile migration to different OS, in profile share(use alternatively) between Linux and Win by mounting NTFS drive of Win on Linux.
And, mail.server.server#.directory-rel=[ProfD]Mail/x.y.z won't produce problem in such case, because profile directory is indirectly pointed via profiles.ini. "Drive letter in Win for profile directory" is successfully hidden in profiles.ini, and because profiles.ini is file owned by Tb, it's not affected by OS's particularity.
(In reply to WADA from comment #11)
> Yuri : 
> What absolute path in what prefs.js entry or what file actually caused
> non-portability problem in your environment?
> Merely "You saw absolute path in panacea.dat and mail.root.imap, so you are
> claiming relative path should be used by Tb"?

I didn't experiment with individual paths. I observed that after moving profile from /usr/home/user1/.thunderbird to /home/user2/.thunderbird it wasn't picked up. It picked an account name string, but that's it. TB showed with just an account name but without folders. I grepped for the user name, and found multiple occurrences of the old .thunderbird path, which is not valid any more. I replaced all of them in prefs.js and panacea.dat and it worked. I also know that this directory was created with all default locations, no any special paths were ever specified.

From the above it seems obvious that full paths were a problem, and fixing them fixed the issue.

Now, if in such case every full path had been replaced with the corresponding tag when possible (and in default case like this it is possible in every single line), the problem wouldn't have existed, wouldn't it? And if the user would specify some other path, this is fine too, then just put it there.

I am not sure where I am going wrong here. Do you claim that this solution wouldn't fix the portability? Obviously it would in such default case. Do you claim that this is difficult to implement? It doesn't appear to have a potential for this.
Yuri, so you also copied the mail data, in the Local directory of each account?
We can try to reproduce that.
(In reply to Yuri from comment #12)
> It picked an account name string, but that's it. TB showed with just an account name but without folders.

Did you saw "slow script" like alert and reply "stop execusion" like response to it?

> I grepped for the user name, and found multiple occurrences of the old .thunderbird path, which is not valid any more.

Have you checked mail.server.server#.directory-rel?

If mail.server.server#.directory-rel = [ProfD]ImapMail/imap.xyz.com like one is already set, it's pretty natual.
If no mail.server.server#.directory-rel entry in prefs.js, it's also natural, because you changed mail.server.server#.directory to expected location which corresponds to [ProfD]ImapMail/imap.xyz.com in copied profile too, although I can't think any mail.server.server#.directory-rel didn't exist in prefs.js after profile copy.

> moving profile from /usr/home/user1/.thunderbird
>                  to /home/user2/.thunderbird

Is "/home/user2/..." in "to /home/..." absolute path in file system of Linux? (not ~/... like one)
How did you request and use the copied profile directory at new machine?
Via profiles.ini on new machine? or command line parameter?

Directory which you call by "[HomeD]" like notation is following?
  Old machine : [HomeD] == /usr/home/user1/
  New machine : [HomeD] == /Home/user2/

Did/do you use mail directory outside of Tb's profile directory? 
  Indside of profile :
    mail.server.server#.directory-rel = [ProfD]ImapMail/imap.xxx.com
  Outside of profile :
    mail.server.server#.directory-rel = [ProfD]../ ... /../Root/ABC/ImapMail/imap.xxx.com

Directory which I call [ProfD](and Tb actually uses) is;
  Old machine : [ProfD] == /usr/home/user1/.thunderbird
  New machine : [ProfD] == /home/user2/.thunderbird

If a resouce is located under Tb's profile directory and is defined as [ProfD]/abc/def, "relative path of the resource from Tb's profile" won't be altered by "profile copy to any location".
If "depth of Tb's profile directory" is not altered by "profile copy", "relative path of an existent resouce at any location" is not changed by profile copy, as far as absolute path of the existent resource is kept.

Because [ProfD] in old machine is one level deeper than one in new machine in your case, "relative path of /Root/XYZ/Server/Folder from Tb's profile directory" is different between old machine and new machine.
This is problem I repeatedly explained, which I called "rather problem due to relative path is used".

However, "mail directory of any account" was finally located at standard location, under Tb's profile directory in your case, and you grep'ed for absolute path only, I believe mail.server.server#.directory-rel=[ProfD]xxx/yyy was kept through out your profile migration and your actions after profile copy.
> I replaced all of them in (snip) and panacea.dat.
IIUC, panacea.dat is also a MorkDB. So, I believe "replacing usr/home/user1 by /home/user2" is merely "manual corruption of panacea.dat file". To change string in panacea.dat, xxx.msf etc. manually using Text Editor, "keeping string length in a block" is mandatory.
Or length of usr/home/user1 part was fortunately absolutely same as length of /home/user2 part?
FYI.

> moving profile from /usr/home/user1/.thunderbird
>                  to /home/user2/.thunderbird

After profile copy, following is normal, because "copy of a directory".
Content in prefs.js is not altered.
 Original /usr/home/user1/.thunderbird/prefs.js
   mail.server.server#.directory-rel = [ProfD]Mail/pop3.xyz.com
   mail.server.server#.directory     = /usr/home/user1/.thunderbird/Mail/pop3.xyz.com
 Copied   /home/user2/.thunderbird/prefs.js
   mail.server.server#.directory-rel = [ProfD]Mail/pop3.xyz.com
   mail.server.server#.directory     = /usr/home/user1/.thunderbird/Mail/pop3.xyz.com
     /usr/home/user1/.thunderbird/Mail/pop3.xyz.com
     is already copied to next file by your profile copy.
     /home/user2/.thunderbird/Mail/pop3.xyz.com
Regardless of "you alter mail.server.server#.directory in copied /home/user2/.thunderbird/prefs.js, or not",
when Tb is restarted using the copied /home/user2/.thunderbird/prefs.js,
mail.server.server#.directory-rel = [ProfD]Mail/pop3.xyz.com is used by Tb as long as mail.server.server#.directory-rel exists,
then /home/user2/.thunderbird/Mail/pop3.xyz.com is used as mail directory,
and mail.server.server#.directory = /home/user2/.thunderbird/Mail/pop3.xyz.com is set for backword compatibility.

Problem in it is: (already known problem which I explained multiple times)
  Because path in panacea.dat is absolute path, data in panacea.data is not usable.
  So, folder re-discovery is needed and directory scan of all directories for mail folder
  file is invoked upon first restart of Tb after profile copy.
Your challenge of "change path in panacea.dat" was correct and good as "workaround of this issue", if "absolute path string length" was not changed by your profile copy.

Because what was done was "copy of directory", "all files pointed by absolute path in panacea.dat" usually actually exists. So, excess directory/file access for them is perhaps invoked upon first restart of Tb after profile copy. "Manual corruption of panacea.dat by you" might have reduced time required for "folder re-discovery process / directory scan".
(In reply to WADA from comment #16)
> Problem in it is: (already known problem which I explained multiple times)
>   Because path in panacea.dat is absolute path, data in panacea.data is not
> usable.
>   So, folder re-discovery is needed and directory scan of all directories
> for mail folder
>   file is invoked upon first restart of Tb after profile copy.

You don't seem to understand my suggestion, no matter how many times and in how many ways I tried to slice and dice it.

I will try to put it in a very short form:
*Please redefine all paths in prefs.js and panacea.dat so that they aren't always full paths, and will include [ProfD] and [HomeD] every time it is possible.*
Who can accept your sugestion like "you saw absolute path in mail.root.imap or mail.server.server#.directory, so you request relative path in it"?
Your request of "use relatve path in mail.root.imap or mail.server.server#.directory" part is nonsence. As I already repeatedly explained, they are "entry defined as absolute path", and they are for backward compatibility, and they are never used by current Tb unless you intentionally delete mail.root.*-rel or mail.server.server#.directory-rel.
And, as I already wrote repeatedly, problem due to absolute path in panacea.dat and extensions.ini is already known problem and is already reported.
There is no need to state about already known problems repeatedly.

Even if your sugestion of "relative path should be used as many places as possible" is correct, and even if your request of "make [HomeD] like notation possible" is reasonable and undestandable, as far as "nonsence" is contained in your suggestion or request, it will not be accepted.
As far as you continue requesting "[ProfD] at some places" even though it's already used by Tb, your suggestion or request is nonsence.

I'm trying to extract following which is relevant to portability of profile directory from your statements which you call "your suggestion",
(a) Absolute path in which prefs.js entry causes what kind of non-portability problem.
    Note: Still nothing is provided by you for this yet.
(b) What kind of portability problem may occur in current [ProfD] use in prefs.js.
    Note: I already pointed this kind of issue in .directory-rel.
(c) [HomeD] like notation is usable or useful in which kind of prefs.js entry.
    Note: I already referred to it. Possibility in *-rel and .directory-rel.
          Possibility in "save directory" like one.
(d) What kind of portability problem may occur if [HomeD] like notation will be introduced.
    Note: I already pointed this kind of issue when [HomeD] is used in .directory-rel.
(e) What kind of [BaseD] like notation is possible, usable, or useful, at where.
(f) What kind of portability problem may occur if such notation will be introduced.
and, am tryng to stop your repeated request of "don't use absolute path in panacea.dat/extensions.ini", because it's already well known, already reported problem.

And, because nothing for (a) is provided by you yet, even though (a) is pretty easy/simple job if (a) actually exists in current prefs.js, i'm trying to know what happened during your profile migration, or by your correct(or bad) actions after profile directory copy. 
Please note that following is nonsence, at least in Tb on MS Win.
  You experienced problem due to absolute path in panacea.dat during profile migration.
  You found absolute path in panacea.dat.
  You found absolute path in mail.root.imap.
  You also found absolute path in mail.server.server#.directory.
  So, request relative path in mail.root.imap or mail.server.server#.directory or others
  in prefs.js file.
What kind of non-portability problem, which was actually caused by "absolute path in prefs.js", actually occurred during your profile migration?
mail.root.imap-rel and mail.server.server#.directory-rel is not written/not used by Linux version of Tb?
I will yet test the migration of profile on Linux to see what does not work.

It is true that panacea.dat is not movable. However, what harm does it cause. WADA, do you know what information it stores? Is it safe to delete it and TB recreates it without much loss of state?
(In reply to :aceman from comment #19)
> WADA, do you know what information it stores?

I don't know, but Yuri(bug opener) and me could know that "at least relation between Mbox name and path of file which is written as absolute path" is held in panacea.dat by Text Editor.

> Is it safe to delete it and TB recreates it without much loss of state?

"Cached data" is merely a "Cached data".
If data can be re-constructed from other data, it may be re-constructed, but it may not be-reconstructed.
If data can not be re-constructed from other data, it is not re-constructed.

Because panacea.data is mainly used for "folder cache", and because the "relation between Mbox name and path of file" is a "folder cache data", as for the "relation between Mbox name and path of file in paacea.dat", it's not affected by "delete panacea.dat". Because of "cached data", it's always recreated by Tb form existent/persisent data such as mail.server.server#.directory-rel, existent Folder/Folder.msf/Folder.sbd file/directory.

If IMAP, and if IMAP server access is impossible after "delete panace.dat", all mail data of an Mbox" is re-fetched and re-downloaded to Offline-Store file by auto-sync, because "relation between Mbox name and path of file" is lost by "delete panacea.dat"(or by profile copy) and "Mbox name at server can't be obtained from server" due to "server access is impossble".
Some users may call this "auto-sync again" "data loss", because such some users believe "offline-store file is a local mail data base" which is absolutely same as "local mail data saved in local mail folder in POP3".
However, it's never "data loss", because all mail data is always held at server in IMAP, and because "Offline-Store file" is merely　a kind of "Cache for mail data" in IMAP.
Read thru bug 701688 and bug 881966 for this kind of issues in this case.

If local mail folder(POP3, Local Folders), "problem around mail folder file after profile copy caused by absolute path in panacea.dat" is essentially absolutely same as phenomenon when panacea.dat is intentionally deleted.
Phenomenon is simply;
  "relation between Mbox name and file name" is lost by;
     - somehow panacea.dat is broken ("absolute path or not" is usually irrelevant)
     - delete panacea.dat            ("absolute path or not" is absolutely irrelevant)
     - profile directory copy        (absolute path is cause of "loss of relation")
  So, it's re-constructed from mail.server.server#.directory-rel and existent
  Mbox/Mbox.msf/Mbox.sbd file/directory.
  Because "re-construct from existent Mbox/Mbox.msf" part involves directory scan of
  all directory which is set in all mail.server.server#.directory-rel and all *.sbd
  directories under them, it takes long.
  It's simply;
    - directory search by OS takes long. 
    - the directory search by OS takes longer if located on file share server.
    - if N directory is scanned, it takes N * "time to scan a directory".
    - Inefficiency in Tb's folder re-discovery code may be involved.
This is well known in some bugs, and phenomenon of "takes long" can easily be observed by "intentinal delete of panacea.dat". But I don't know whether specific bug already exists for this kind of issue after "profile copy".

Both "issue in IMAP" and "issue in local folder" can happen by "profile copy", because data held in panacea.dat is absolute path. So I asked about his environment or phenomenon.
But nothing is returned from bug opener yet. Bug opener merely says "I saw absolute path in mail.root.imap in his prefs.js, I saw absolute path in his prefs.js, I saw absolute path in panacea,dat"...

> Is it safe to delete it and TB recreates it without much loss of state?

I don't know what kind of data is saved in panacea.dat, so I can say nothing.
However, I can say following;
  If Tb saves data, for example, "sort order at a thread column", in panacea.dat,
  it's lost by intentional delete of panacea.dat file.
  This may be a "data loss", but it may not be "data loss".
  Such data may be re-construced from other data by Tb,
  but such data may not be re-constructed from other data by Tb.
This kind of issue is always applicable to "manual delete of a .msf file" too.
- Thread column choice of the folder is always lost by delete .msf.
  It may be re-set from current Inbox setting, but it may be set from "internal default".
- Tag is always lost by delete .msf if IMAP server doesn't support user defined keyword.
  Because Tag data is held nowhere after delete .msf, Tag can not be recovered.  .
Oh, bug opener of bug 881966 already had opened bug 883645, according to my recommendation at somewhere.
> Bug 883645 Use relative paths in panacea.dat and other settings
Even though I pointed "Bug 344671 was already closed as WONTFIX", he looks to have included extensions.ini in his request...
FYI.
If many mail folders are used(local mail folders?), and if Tb 24, following can occur upon first restart of Tb after profile directory copy.
 Due to slowness in directory scan which is needed because of absolute path in panacea.dat,
 and due to performace issue upon restart of Tb 24 like bug 950528 which is caused by 939462,
 warning of "Unresponsive script" may be shown.
 Needless to say, if user stops the script execution while script for folder re-discovery,
 directory scan etc. is running, mail folders are not shown at folder pane,
 because user canceled job to display mail folders at folder pane.
 "Empty folder pane" in bug 950528 seems phenomenon after "stop script execution" reply.

FYI.
Followins is a part of comment #12 by bug opener, which is about "what he did and saw upon his profile migration".
> I observed that after moving profile
>   from /usr/home/user1/.thunderbird
>     to /home/user2/.thunderbird it wasn't picked up.
> It picked an account name string, but that's it. 
> TB showed with just an account name but without folders.
> I grepped for the user name, and found multiple occurrences of the old .thunderbird path
> (snip)

FYI.
According to above comment and other statements, mail.server.server#.directory-rel=[ProfD}Mail/severname like setting should be kept through out the migration and replacing "absolute path string which he saw in prefs.js and panacea.dat".
If this is right, I can't imagine other than "Unresponsive script followed by stop script execution reply" as cause of "just an account name but without folders" upon the migration, because;
- By "replacing absolute path in prefs.js",
  mail.server.server#.directory-rel won't be changed.
- Even if panacea.dat file is deleted, local mail folder is shown correctly sooner or later
  after restart of Tb.
  Even if panacea.dat file is deleted, if imap server access is possible,
  imap mail folders are shown correctly sooner or later after restart of Tb.
- "Replacing string in panacea.dat file" is merely a "corruption of data in panacea.dat",
  unless string length is kept absolutely same by the "replace string".
  Even if same string length is kept and the "string after replace" is correct,
  it's irrelevant to "mail folders are shown at folder pane after restart of Tb or not,
  because mail folders are shown even after "delete panacea.dat".
  It's relevant to "time needed to show mail folders in folder pane" only.
One additional reason.
- Because of "profile copy to different depth", problem of ".directory-rel points wrong
  place" can occur, if "mail directory outside of profile directory" is used. 
  However, this problem never disappers by "correct absolute path in
  panace.dat" nor "correct absolute path in mail.server.server#.directory in prefs.js"
  because Tb always uses "mail.server.server#.directory-rel", unless spec of Linux version
  of Tb is "never write/use mail.server.server#.directory-rel, use .directory only".
  At least "delete mail.server.server#.directory-rel" or re-selection at "Local Directory:"
  is neaded to resolve problem of ".directory-rel points wrong place".

(In reply to :aceman from comment #19)
> I will yet test the migration of profile on Linux to see what does not work.

What kind of test will you do? Confirm following?
- Linux verion doesn't write/use .directory-rel.
- "Restart of Tb after profile copy with delete panacea.dat or manual panacea.dat
  corruption" is perhaps faster than "Restart of Tb after profile copy without delete/break
  panacea.dat, with keeping same panacea.dat content as original profile which points
  'existent/valid files in the original profile but not usable by copied profile'".
See Also: → 888371
Blocks: 1774953
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.