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.
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
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 :-)
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
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
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>.
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.
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. ***
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.
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.