in addition to bug #137006, we should look into other places where we store absolute paths that would make moving profiles problematic. other files (besides prefs.js) that we store absolute file paths (panacea.dat, filter files, downloads.rdf, secmod.db)

*** Bug 186530 has been marked as a duplicate of this bug. ***

My compref.dat in an opt, objdir build contains all full paths: [COMPONENTS] abs:/Volumes/Vertigo/Projects/macho_objs/opt/dist/Mozilla.app/Contents/MacOS/components/venkman-service.js,1044408375000 abs:/Volumes/Vertigo/Projects/macho_objs/opt/dist/Mozilla.app/Contents/MacOS/components/libpippki.dylib,1050106921000 this cannot be good. What if I rename my disk?

how were this files registered?

Just by running the build. Every xpcom component has a full path. (Note that they are symlinks to libs in the tree, but that the paths in the file are paths into components/).

assign the bug over to me and I will take a look. I don't see this on either linux or windows.

They contain full paths in builds where the components are symlinks. This is because the component mgr checks the parent of each found component and, only if it is the components dir, is the path relative. In a build with symlinks, the parent of the component file itself is not the components dir - it is only for the link which pointed to it. This doesn't happen (1) in release builds because the items in the components dir are not symlinks (2) with my patch for bug 164396 because, like the other platforms, the parent is determined just from the path, not the actual file object.

In Linux the appreg file in the $HOME/.mozilla has absolute filenames. This is really a pain in the ass as when the user's home is moved, the profiles are unusable.

[profile]\chrome\chrome.rdf contains absolute paths to extensions' jars. If there is a bug for this already, it should be added to dependancies.

Adding a firefox-only bug 280199 (profile's compreg.dat), hope you don't mind.

No comment in 3 years - resetting A+QA: takers welcome

Unfortunately, this is *still* a valid bug affecting thunderbird. An easy way to check is: cd .thunderbird grep -r --exclude="Mail/*" "/home/USERNAME" * (where USERNAME is your username).

note that, as shown by e.g. serverN.directory in prefs.js and bug 280199, the presence of absolute paths in files is not a sufficient condition for there being problems arising from such paths being stored.

For people who have to restore profiles due to disaster results - they really don't need more problems added to the process of restoring and getting their system running again. Also problematic for testers who copy profiles to accomplish testing. If anyone believes this to be datalossy, please change accordingly

Fortunately, on Linux/Mac, it's easy to workaround - though the pain on XP must be awful. The workaround is just to manually create a symlink from where thunderbird insists that the profile is, to where thunderbird actually put the profile last time. It's trivial to fix, but most users won't discover the workaround. Incidentally, this bug is well over half a *decade* old, but would take hardly any time to fix. Any chance of some of these "old-faithful" bugs getting some love sometime?

On windows you could create symlink too but this only available to hard core admins ;) who get real dzen of Windows

As a metabug, I don't think this is being tracked by anyone in particular, so I'm just going to close it.

See also: Bug 929406 - Inbox etc. not translated to locale after switch to Ubuntu Bug 888371 - Windows paths in prefs.js should be updated after moving profile to Linux OR "mail.server.serverX.directory" property should be removed completely