66259 - Profiles should be transportable (movable)

Status: RESOLVED INCOMPLETE

(Core Graveyard :: Profile: BackEnd, enhancement)

Description

[Paul Gregg]

User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; m18) Gecko/20010122
BuildID:    2001012205

Profiles should be movable, so that you can take a profile from one machine to
another, or return it after a reinstall (maybe even XP)

This Bug can be a container for all the different "profile component" bugs
(history, prefs, themes etc. moving problems)


Reproducible: Always
Steps to Reproduce:
1. Copy currect profile directory contents to a temp location
2. Create a new profile
3. Copy files from Step 1 in new profiles directory (remember the salting)
4. Launch Mozilla (or any distribution)

Actual Results:  Certain features of a profile work, and some do not

Expected Results:  Profile acts as before


I found this when M18 killed my nightly's profile about a month ago.
Ever time I launched the nightly, the search & print buttons on the navbar keep
reappearing, and the bookmarks button on personal toolbar wouldn't show, even
after reapplying the prefs.
So I tried creating a profile from scratch, and moving the profile files over in
chunks at a time to see what part was causing the problem. It turned out to be
the localstore.rdf file. (prefs.js did contain the right settings, but the
buttons wouldn't appear properly with the old localstore.rdf).


Observations
1. Salting doesn't seem to create problems, but you do need to be aware of it
   (see below)
2. Bookmarks file copied over worked great :-) !!!
   But see point 9
3. Prefs file moved over pretty easily (as long as paths to mail/news etc. were
altered - salting taken into account). Could be resolved with relative pathnames
in prefs.js
4. Mail/News, copy over both the Mail and News directories, alter the absolute
paths to reflect new profile in prefs.js -> no observed problems
5. Chrome, copying chrome directory over (with possibly new themes in jar's)
doesn't seem succesful, added themes wouldn't work (didn't switch over)
6. History, tried copying over "History.dat" and "History.mab", previous history
didn't work at all, and any history during program run was lost when firing up
Moz again, so history only lasted for the current session.
7. Sidebar, copying over "panels.rdf" seemed to work fine (seems no panels had
any outer dependancy - do they ever?)
8. Cookies, copying over "cookies.txt" and "cookperm.txt" seemed to work fine,
cookie and images blocking works doing it this way!!
9. "Localstore.rdf", seems to have lots of added applications settings (added
themes, Chatzilla, etc.), theme settings (window positions of nav, messenger,
editor..), urlbar history, some bookmark settings (IE Favorites rip), a general
dumping ground of settings.  This particular file caused the problems that I was
seeing, so I couldn't copy it over. May work if not already corrupted. Lost
URLbar history :-(  IE favorites linkage doesn't work properly now, maybe coz of
mismatch between "bookmarks.html" and new "localstore.rdf"
10. Cache, didn't try
11. "mimeTypes.rdf", didn't try
12. "search.rdf", didn't try
13. "panacea.dat", appears something to do with mail, didn't try
14. "abook.mab", Addressbook I guess, don't use, so didn't try
15. "cert7.db", "key3.db" & "secmod.db", I think have to do with security,
didn't try
16. "68922816.s" & "72527158.w", no idea, look like temp files of some kind
(Form data??), didn't try

Will add bugs for above items if (item is a problem && no duplicate already &&
there is interest in this bug)

If these items are corrected, then roaming profiles (Bug 17048 & Bug 31732 that
I know of) should be easier to implement...

This bug is related to Bug 22689, which is about a tool to do
importing/exporting, and modifying mozreg.dat for adding/editing profiles
(during import/export).  This bug is a container for all the specific bugs
relating to "components of profiles" (prefs, mail/news, cache, history etc.) 
About half work fine, and the other half need work or at least doco on know to move.

Comment 1

[Paul Gregg]

Bug 65994 could be related to problem I saw with localstore.rdf taking over prefs.

Adding Ben Bucksch to CC: as he maybe interested from a distribution/enterprise
profile perspective

Adding this as a blocker to Bug 22689

Comment 2

[Ben Bucksch (:BenB)]

I'd say, this is eotehr a dup of bug 22689 or simply a bug about localstore
being to version-sensitive. The latter is a bad bug, but should IMO be filed
independantly.

Comment 3

[Conrad Carlen (not reading bugmail)]

Although there is a lot of info here, as far as the summary of this bug goes, I
absolutely agree. Profiles do need to be movable. The thing preventing that is
absolute paths (instead of relative paths) which are used all over the place
both in the profile registry and various files within a profile. While not an
exact dup, this problem has been mentioned in many, many bugs and I'd like to
solve it. See my post to n.p.m.xpcom on 12/22 - "XP, relative file specs" If we
had that, it would be easy to solve this. 

Comment 4

[Conrad Carlen (not reading bugmail)]

Found a related, if not dup - bug 12911. As for the other problems mentioned
here such as localstore, history, chrome should be filed against those specific
components - like you said :-)

Comment 5

[jsnod]

cc-self

Comment 6

[Peter Lairo]

if not transportable, then at least updatable with new features of newer versions.

Comment 7

[Aleksander Adamowski]

I think that bug 12911 blocks this bug rather than be a duplicate. Adding 12911
to this bug's dependency list.

Comment 8

[Aleksander Adamowski]

Uhm, sorry, the dependency chain should be:
- bug 7067 blocks this bug
- bug 12911 blocks bug 7067

correcting...

Comment 9

[Asa Dotzler [:asa]]

Bugs targeted at mozilla1.0 without the mozilla1.0 keyword moved to mozilla1.0.1 
(you can query for this string to delete spam or retrieve the list of bugs I've 
moved)

Comment 10

[Conrad Carlen (not reading bugmail)]

Setting to milestone that's not passed.

Comment 11

[Joseph G. Wezensky]

Just got a copy of Firebird 0.6, 

-Installed it at work (WinXP).
-Created a new profile on my nice, keychain usb-flash-drive.
-Setup all my bookmarks, preferences, themes, extentions...
Everything working great.

-Came home (with my usb flash drive of course)
-Installed Firebird 0.6 just like at work (except on a Win98SE machine)
-Started profile manager, pointed it to the profile on my usb flash drive.

    AND IT SALTED A NEW PROFILE.

(Created a new salted subdirectory under my profile directory)

How come it did not just use the profile that I already had setup?

Even moving the files from my old salted directory to the new one 
still caused me to have problems.  In the time it took me straighten
them all out, I could have started with a blank profile and redone 
everything by hand.  The problem is, am I going to have to do the 
same thing, when I go back to work?

In this bug record, I see alot of references to different files, lots of
comments and lots of references to this other bug and that other bug.  Is there
a simple solution to this (I can't tell from all this bugzilla info dumped in my
face).

I can't be the only person with a portable drive that would like to carry his
profile between work and home.

Comment 12

[Ben Bucksch (:BenB)]

> Is there a simple solution to this (I can't tell from all this bugzilla
> info dumped in my face).

BugZilla is not a tech support forum, it tracks code changes and the work on it.
Please see <http://www.mozilla.org/start/1.0/support.html>.

Comment 13

[Jason Logan]

i would like the option like in netscape 4.7, move a profile, the manager tells
you it can't find the profile, offers a browse button, you find the profile and
click OK, it now uses the given path.

Also when converting from 4.7 to mozilla, give the option THEN to store the
profile in a desired folder instead of default.

Comment 14

[Carl Brewer]

not sure if it belongs in this report?  I'd like to be able to 
use the same spam filter, mail filters & address book etc on multiple sites from
thunderbird and/or moz mail.  Is it possible to use an IMAP server to store
these files?  It's not really what IMAP is for, but if you could tell Moz/TB to
store spam rules, filter rules and address book stuff on an imap server, and
then read it from same, then my 4 different machines would have automagically
sync'd settings, which would be very good.  If Moz/TB had a folder on the IMAP
server with its config stuff in it that could be used as a config repository
common to multiple clients?

Comment 15

[Ben Bucksch (:BenB)]

That's "roaming" - bug 17048 / 124029

Comment 16

[Wayne Mery (:wsmwk)]

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

Comment 17

[Timur Fayzullin]

It's so easy to move file "profile.ini" into Firefox folder instead of AppData folder... Amazingly, why it hasn't already done. Look at Opera - they have done it many years ago.

Comment 18

[Benjamin Smedberg]

As filed, profiles are moveable. The profiles.ini file is not, but for things like portable Firefox you can use the -profile commandline flag to specify the location. This is not tracking anything else useful anymore, so I'm going to resolve it.

Comment 19

[Randell Jesup [:jesup] (needinfo me)]

More to the point or more detailed, you can add a copied/moved profile to profiles.ini by -profilemanager, and then selecting the directory you imported/moved.

Comment 20

[Noah (NoahSUMO/SolidSnake) [:Noah]]

Mistakenly marked fixed. For this to be fixed, there would have to be a patch that was checked in via this bug. There was not. Please leave this as RESOLVED INCOMPLETE.

This showed up as being a fixed bug in the Firefox 20 Release Notes, which is false and confused me.

See:
http://www.mozilla.org/en-US/firefox/20.0/releasenotes/buglist.html