Closed
Bug 66259
Opened 24 years ago
Closed 12 years ago
Profiles should be transportable (movable)
Categories
(Core Graveyard :: Profile: BackEnd, enhancement)
Tracking
(Not tracked)
RESOLVED
INCOMPLETE
mozilla1.5alpha
People
(Reporter: paul_gregg, Unassigned)
References
Details
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•24 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
Comment 2•24 years ago
|
||
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•24 years ago
|
||
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
Comment 4•24 years ago
|
||
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 6•24 years ago
|
||
if not transportable, then at least updatable with new features of newer versions.
Comment 7•23 years ago
|
||
I think that bug 12911 blocks this bug rather than be a duplicate. Adding 12911
to this bug's dependency list.
Depends on: 12911
Comment 8•23 years ago
|
||
Comment 9•23 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
Summary: [RFE] Profiles should be transportable (movable) → Profiles should be transportable (movable)
Comment 10•22 years ago
|
||
Setting to milestone that's not passed.
Target Milestone: mozilla1.0.1 → mozilla1.5alpha
Comment 11•22 years ago
|
||
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•22 years ago
|
||
> 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•21 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•21 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?
Comment 15•21 years ago
|
||
That's "roaming" - bug 17048 / 124029
Comment 16•18 years ago
|
||
*** Bug 113694 has been marked as a duplicate of this bug. ***
Updated•15 years ago
|
QA Contact: agracebush → profile-manager-backend
Comment 17•13 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.
Comment 18•12 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
Closed: 12 years ago
Resolution: --- → INCOMPLETE
Comment 19•12 years ago
|
||
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•12 years ago
|
Assignee: ccarlen → nobody
Resolution: INCOMPLETE → FIXED
Comment 20•12 years ago
|
||
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
Assignee | ||
Updated•9 years ago
|
Product: Core → Core Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•