Profiles should be transportable (movable)

RESOLVED INCOMPLETE

Status

enhancement
RESOLVED INCOMPLETE
19 years ago
3 years ago

People

(Reporter: paul_gregg, Unassigned)

Tracking

Trunk
mozilla1.5alpha
x86
Windows NT

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

19 years ago
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.
(Reporter)

Comment 1

19 years ago
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
Blocks: 22689
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.
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. 
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Target Milestone: --- → mozilla1.0
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

19 years ago
cc-self

Comment 6

19 years ago
if not transportable, then at least updatable with new features of newer versions.
I think that bug 12911 blocks this bug rather than be a duplicate. Adding 12911
to this bug's dependency list.
Depends on: 12911
Uhm, sorry, the dependency chain should be:
- bug 7067 blocks this bug
- bug 12911 blocks bug 7067

correcting...
Depends on: 7067
No longer depends on: 12911

Updated

18 years ago
No longer depends on: 7067

Comment 9

18 years ago
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)
Target Milestone: mozilla1.0 → mozilla1.0.1

Updated

17 years ago
Summary: [RFE] Profiles should be transportable (movable) → Profiles should be transportable (movable)
Setting to milestone that's not passed.
Target Milestone: mozilla1.0.1 → mozilla1.5alpha
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.
> 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

16 years ago
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

15 years ago
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?
That's "roaming" - bug 17048 / 124029
*** Bug 113694 has been marked as a duplicate of this bug. ***
QA Contact: agracebush → profile-manager-backend

Comment 17

8 years ago
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.
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.
Status: ASSIGNED → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → INCOMPLETE
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.

Updated

6 years ago
Assignee: ccarlen → nobody
Resolution: INCOMPLETE → FIXED
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
Resolution: FIXED → INCOMPLETE
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.