Closed Bug 77924 Opened 19 years ago Closed 9 years ago

Move Profile button


(Toolkit :: Startup and Profile System, enhancement)

Not set





(Reporter: timeless, Unassigned)



Expected Steps
Select a profile from the profile list
Click Move Profile
Receive a dialog prompting for a destination directory.

Expected Results
Profile is moved to new location, and reference to profile is updated.
The tough part here is updating all of the absolute paths that are written into
files within the profile dir - mainly prefs.js. I've been wanting to write the
paths within the profile dir as relative paths - then they could be moved
painlessly without any effort beyond updating the registry entry. Or, something
could be done with nsIPrefBranch::GetChildList(), and  operate on the prefs
which were an nsILocalFile. That's ugly though.
Profile Manager FE bugs --> me
Assignee: ben → blakeross
Conrad, I haven't looked into this yet, but does the backend support this 
Blake - no. If my comment from 2001-04-27 12:49 is what you're talking about.
It's no sweat for the backend to do this. The part that would be work is
changing all the consumers of absolute file path prefs. There are other reasons
to solve that problem as well and I know how to do it.
changing QA contact
QA Contact: gbush → ktrina
--> ben
Assignee: blake → ben
*** Bug 98137 has been marked as a duplicate of this bug. ***
Target Milestone: --- → Future
Depends on: 125721
*** Bug 124727 has been marked as a duplicate of this bug. ***
I've marked this a dup of Bug #124727.
I also added the dependancy from that bug.

Here are some additional comments from Bug #124727 that may be useful.

This is a good idea, but would need to be implemented first,
since there is no way to specify the alternate profile location?

From me:
This bug is more about haveing an automated way to move the profile directory
and update the related pref.js settings that refer to the hard coded profile

Maybe I am completely wrong here, but isn't prefs.js *part* of the profile
directory? How can one move the profile directory (under linux it 
always is ~/.mozilla) and still have mozilla be able to use it?
If I want to move .mozilla to a different disk there is no way to 
tell mozilla where to find it AFAIK.

From me:
You are, of course, absolutely correct.

Now, I think what I did was to edit mozregistry.dat (which on a Win98 system
resides in the Windows directory) to point to the new location. Now, the file
isn't really intended to be edited, so I had to be very careful to not break any
of the other data in the file.

I don't know if Linux has such a file, nor where it would reside.
end of copying.

>I don't know if Linux has such a file, nor where it would reside.

*** Bug 163520 has been marked as a duplicate of this bug. ***
Comment #9
I think the "move profile" button should be used when you want to
store the big user data in another place. For example: all the mail, news, 
cache files.
So, we could separate the mozilla user files in 2 section, the ones that
can be moved and the ones that can not be moved.
For my case, I want to store all mozilla big files to a network drive
in WinXP, because I use roaming profiles and 60MB of mozilla data makes
my login time too long, because it has to be move to my WinXP profile.

So, I would have, say 5MB of mozilla files in my WinXP Profile and the
other 55MB of mozilla data(mail, news, cache) in one network drive.

For Linux, this 5MB should always be in the ~/.mozilla/ directory and
the other 55MB wherever you want(an NFS directory maybe).

I think this solution can solve the Linux issue and also win no need to
modify a system wide file (\windows\mozregitry.dat)
*** Bug 182565 has been marked as a duplicate of this bug. ***
5MB?  Why so much?  My C:\Documents and Settings\malcolm\Application
Data\Mozilla folder has three items: 

* File: pluginreg.dat (13k)
* File: registry.dat (2k)
* Folder: Profiles (178MB)

There are no more files under the Profiles folder until I get all the way down
in to the salted directory.  Surely all we need is another very small file at
the top level (e.g. profiles.dat) that maps profile names to locations.  Yes yes
yes, I'm sure moving the profile directory will break many things as people do
like using absolute paths for some reason.  Besides this one small file, what
else would we need in the *Windows* profile directory?  Am I missing something
on other platforms?

Question: is there any concurrency protection in profiles?  I.e. can the same
profile be opened by two or more users/sessions concurrently?
There is concurrency protection in profiles. Well, put it this way, I had
Mozilla running, and then I started Netscape 7.0 and tried to select the same
profile as was being used by Mozilla. I got an error message about the profile
already being in use.
> Surely all we need is another very small file at
> the top level (e.g. profiles.dat) that maps profile names to locations. 

registry.dat does _exactly_ that, and I even think that these days it does only

however, moving a profile needs to adjust the path in prefs.js and other files.
It the meantime, profiles have to be moved by hand, see .
Mass reassign of my non-Firefox bugs to
Assignee: bugs → ben_seamonkey
*** Bug 233070 has been marked as a duplicate of this bug. ***
Product: Browser → Seamonkey
I'm running into this problem on Firefox (out of disk space on c:, need to move
profile to d:) is this a separate bug, or does 'Mozilla Application Suite' (or
at least the profile manager, in this case) cover Firefox for this issue as well?

Funny thing is, I was able to move profile 'Alpha' by creating a new profile
Alpho, copying Alpha's data into it, and deleting Alpha. 

I wasn't able to do the same with profile Bravo; I created Bravu on d:, copying
Bravo's data in, and deleted Bravo.  Then on starting Firefox, the UI came up
but clicking didn't change focus to the location bar, it didn't go to the start
page, etc.
I have filed similar bug for Thunderbird, as bug 280852. Someone suggests that
it should be marked as a duplicate of this bug, but I'm not completely sure, as
it refers to another application and this is a user interface problem and not
the engine problem.
(In reply to comment #17)

> is more to the point, IMO.

Guys, can we see some action on this bug? It's over four years old!
Assignee: ben_seamonkey → nobody
QA Contact: ktrina → profile-manager
Approaching on *6* years.
Component: Startup & Profiles → Startup and Profile System
Product: SeaMonkey → Toolkit
QA Contact: profile-manager → startup
As far as toolkit is concerned this is wontfix... we are removing the profile manager in bug 214675. There is bug 539524 to provide a profile manager when the current profile manager is removed and if you would like the requested functionality added to it feel free to reopen this bug and move it over to Testing -> Profile Manager.
Closed: 9 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.