Closed Bug 55309 Opened 24 years ago Closed 8 years ago

Need an option to store migrated profiles in a user's choice of location

Categories

(Core Graveyard :: Profile: Migration, defect, P3)

Product:
Core Graveyard
Component:
Profile: Migration
Platform:
x86
Windows NT
Type:
defect

Tracking

(Not tracked)

Status:
RESOLVED INCOMPLETE
Milestone:
Future

People

(Reporter: david, Assigned: ccarlen)

References

Details

(Keywords: helpwanted) 

On NT, the cache directory plus all user profile information plus user
preferences is stored in the user's roaming profile.

At first glance, this looks like an okay idea.  However, some sites such as
Purdue University put as low as a 2MB quota on your roaming profile (yes, even
for faculty).  With multiple large IMAP accounts inside Messenger, it is *easy*
to exceed this quota just with the data that Messenger stores about each IMAP
folder.  That's before *any* cache data gets stored on the disk at all.

Since the cache and IMAP data can be regenerated easily enough at each
workstation, I propose that at least this data should be stored outside the
user's roaming profile at the very least.  The nicest solution would be to make
it an option to selectively move IMAP data, cache data, and/or all user
preference data out of the roaming profile to some other directory.  The easiest
solution would probably be an option to just move *all* Mozilla application data
to a user-specified directory.
over to racham@netscape.com, if this isn't yours perhaps you know who should get it.
Assignee: asa → racham
Status: UNCONFIRMED → NEW
Ever confirmed: true
This is a valid concern...

Also, let's not call it as a roaming profile. Because in 4.x profile world,
roaming profile had a whole new meaning.

You are saying we should have an option to store the data in a place other than
Application Data folder as one may easily run into disk space problems. And you
should note that this primarily applicable to migrated profiles (profiles
migrated from 4.x).

In 6.0 itself, as a user you always an option to put your profile directory in
any location you wish to..So, new profiles should be fine as user has a way to
store them where he/she wants.

Coming to this bug, we don't want to store prefs in one place and the remaning
data in another place..So, let's keep them all in one place. So, a good solution
here will be provide an option to the user to store to be migrated profiles in
his/her choice of location.

To that affect, I am changing the summary to "Need an option to store migrated
profiles in a user's choice of location". If you disagree are talking totally
about something else, please feel free to change the summary back and explain
the core concern.
Status: NEW → ASSIGNED
Summary: Just user prefs should be stored in NT roaming profile → Need an option to store migrated profiles in a user's choice of location
This (mostly) addresses my concerns.  But I think it's a band-aid solution at
best.  Here's why:

When I'm talking about a romaing profile, I'm talking about the NT roaming
profile, not Mozilla/Netscape profiles.  ie: where NT networks store the layout
of your desktop's icons, IE's bookmarks, etc.

In order to have feature-parity with Internet Explorer on NT networks, we still
need to store at least the bookmarks and address book inside the NT Roaming
Profile, so it will be available when a user logs in on other than her home
workstation.  In order to do that, users currently have to have *all* of their
configuration data *plus* their cache directory under
c:/winnt/profiles/[username]/Application Data.

Consequently, if I move all of my config data to a different location (as
proposed in the solution above), then I have to recreate my bookmarks and
address book at *every* NT workstation that I use, because the NT network will
no longer propogate it for me automatically.

I think that the only real solution is to separate stuff that needs to be copied
from workstation to workstation from the rest of the stuff.  (This is what MS
does with IE.)  Store the stuff you want to roam with you under Application
Data.  The rest needs to be stored somewhere else analagous to
c:/winnt/Temporary Internet Files.

> I think the only real way to fix this...

Okay, I think the *real* solution is for MS to fix Windoze and all Windoze apps
so that they have a concept of a home directory. :)  But given Microsoft's
current architecture, I think that the solution I outlined above is the best
solution to this bug. :)

David: you are wrong.
we don't use the literal c:/winnt/profiles/[username]/Application Data.
we use a setting from the system
it effectively is a home directory [well there are ~10 home directories, each 
serves a different purpose]
and in your users cases it should be on the network drive.

If you have questions or want to see this in action, please contact me on irc.

In your instance, the per user application data SHOULD be roaming so it SHOULD 
be on the network drive.

I suggest resolution wontfix, relnote w/ instructions on how to use policy 
editor and or tweakui.

Oh, fwiw, nt has log off scripts so you could always sync c:\Something to 
\\homeserver\user\somethingelse at logoff
> it effectively is a home directory [well there are ~10 home directories, each
> serves a different purpose]

Okay, I won't pick a nit here.  You are right and I am exhibiting my Unix bias
to having a single home directory with subdirectories that serve different
purposes.  But that wasn't the point.

>In your instance, the per user application data SHOULD be roaming so it SHOULD
>be on the network drive.

Agreed.  What I view as a problem is that the web page cache directories are
considered "per-user application data."  Since my per-user application data
quota is so small at Purdue, I don't want stuff that can be regenerated easily
like cache data or per-folder IMAP data to included as part of that per-user
application data.

I hope I've clarified my point.  I'm sorry if I let my pro-Unix bias offend
anyone. :)


Best,

Dave


Conrad,

Bunch of issues are addressed in this bug. There are couple of proposals to fix
some of the issues brought up here..

This will be a good one to work one, if you have time on your hands..
Assignee: racham → ccarlen
Status: ASSIGNED → NEW
Roaming profiles - ones which automatically update to/from one location to
another would be a good feature. You should be able to pick which items within a
profile you want to roam and update. You would probably not want your disk cache
to do this, but somebody might.
	Another point brought up is having some of the data in one place and some in
another. One easy candidate for this would be the disk cache. It reads it
location from a pref and it's even dynamically changeable. There is no UI to set
this pref though. The ability for the user to change this location through a
pref maybe was taken out for some reason (bug) but is worth looking into. At
least having the cache dir outside of your profile dir would help (if not solve)
the data size problem.
Status: NEW → ASSIGNED
Target Milestone: --- → Future
A pref ui for cache is something we need anyways. I think i'll work on that. 
Oh, I do want to be able to roam my cache, especially if I can roam it around 
afs cells.
Keywords: helpwanted
*** Bug 116940 has been marked as a duplicate of this bug. ***
Has work stopped on this bug?  Mozilla 1.1 is now out and seriously needs this
feature, yet there have been no comments since the end of 2000.  We are
currently considering upgrading our 800 users from Netscape 4.5 to Mozilla or
Netscape 7.  However, all N4 profiles are currently stored on a network drive. 
It seems there is no easy or even standard way of upgrading to Mozilla and
keeping the profiles on the network drive.  Instead, they are just converted
from there, and slapped on the c drive.  This is completely useless, as it is
not backed up.  An option to migrate a profile and put it back where it came
from is seriously lacking.  Currently, it looks like we would need to install
Mozilla, then copy the resultant converted profile to the network drive, then
create a new profile and point it to this copied directory.  Having to do this
for each install is proving a major barrier to the upgrade process.
Component: Browser-General → Profile Migration
Keywords: mozilla1.3, nsbeta1, nsenterprise
*** Bug 173705 has been marked as a duplicate of this bug. ***
*** Bug 182564 has been marked as a duplicate of this bug. ***
*** Bug 184281 has been marked as a duplicate of this bug. ***
*** Bug 200898 has been marked as a duplicate of this bug. ***
Hi

It looks that there has been additional reports similar to that bug, but nothing
happens new ..?!
May I suggest that the context has changed: in Mail & News preferences / Account
Name/ Server settings it is possible today (Mozilla/5.0 (Windows; U; Windows NT
5.0; en-US; rv:1.4b) Gecko/20030406)to define the drive and folder holding all
mail folders for this account, and then to have mail data on a different drive
than the one holding Application Data: a new account can be set anywhere, as
desired.

But how do you convert a Netscape 4x account on a different drive ? There is no
option for this in the account manager wizard. Is there any howto documentation
? any other option to do it manually ?

Thanks


I'm going to have a wee look at how easy it would be to fix this. As Olivier 
points out, you can now move your cache / mail etc to a different drive if you 
want to, so from what I can tell, the only remaining requirement of this bug 
is to provide a way to specify a different destination to migrate profiles to 
than the default (NS_APP_USER_PROFILES_ROOT_DIR).
I also suggest to look at the following:
- default suggested drive could be the same as the one currently used by the NS
4.x profile
- migrating a profile includes migration of parameters (etc...) and messages.
While parameters don't require must disk space, messages can represent huge file
sizes and copying them may not be possible (not enough disk space available). It
could be worth offering the option to *move* messages instead of doing a copy of
them (this may however be a risk in case of a possible failure). An other option
could be to offer to only migrate parameters, and provide guidelines to migrate
messages by hand.
> default suggested drive could be the same as the one currently used by the 
> NS 4.x profile

Sounds reasonable.

> It could be worth offering the option to *move* messages instead of doing a copy

Perhaps you could log a separate bug for that? I've far too often seen mozilla
bugs remain open endlessly because the list of stuff to do keeps spiraling wider
and wider from the original request.
There already is a bug about moving not copying messages so please don't create
a new one.  I'm afraid that I can't for the life of me find the bug atm, but do
not create a duplicate - it is there somewhere!
I think I reason is needed:
I like to run phoenix from my own network drive and wish I could store my 
bookmarks there too with out having to go in create a profile on every computer 
I'm working on.
adt: nsbeta1-
Keywords: nsbeta1 → nsbeta1-
*** Bug 188494 has been marked as a duplicate of this bug. ***
*** Bug 218649 has been marked as a duplicate of this bug. ***
has anyprogress been made with the bug regarding the path specification prior to
converting so it deosn't have to be done afterwords... its a pain to do it
afterwords. right now i have to convert, delete profiles from mozilla(not
directory just files). Then i recreate a profile and select where i want it.
Then open email and create a dummy account in the same place. Then i have to
transfer all data behind the random string of old account to behind random
string of new account, overwriting everything. Then i restart mozilla and check
all settings and paths to make sure it is correct.

this would be much easier if the convert process put it where i wanted it in
beginning.
I've posted a patch to bug 24954 which may be better suited to this bug - I need
to sleep though.
With the latest patch to bug 24954 it may be possible to add another setting of:
3 - prompt user for location to use as profile root

Thoughts?
Depends on: 24954
As a SysAdmin I would want the ability to 'Suggest' or 'Mandate' a specific
master profile location due to Network Storage & Backup requirements. Once the
profile is stored in a central location, it could be 'synced' to the mobile
clients. The biggest problem with "Windows Roaming Profiles" is that cached data
is synced over the network, and I have no desire to backup or store the caches.
Could they be excluded?

Linux-Unix-NFS mounts...
  $HOSTNAME/$HOME/$USERNAME/.mozilla/[Unix Login Name]/[randowm string].slt/
Samba-Windows mounts...
  \\SEVER\USERS\%USERNAME%\%APPDATA%\Mozilla\Profiles\[profile name]\[random
string].slt\
MacOS-X...
  ~/Library/Mozilla/Profiles/[profile name]/[random string].slt 

Some related links & bugs which may need to be reviewed....
Mozilla Client Customization Kit (Custom Installer & Profile Manager)
http://www.mozilla.org/projects/cck/

Bugzilla Bug# 124418 - Mozilla CCK deployment barriers
http://bugzilla.mozilla.org/show_bug.cgi?id=124418

Bug# 24954 - [deployment]Need ability to specify with -installer the Users directory
http://bugzilla.mozilla.org/show_bug.cgi?id=24954

Bug# 55309 - Need an option to store migrated profiles in a user's choice of
location
http://bugzilla.mozilla.org/show_bug.cgi?id=55309

Bugzilla Bug# 7067 - All profile contents should use cross-platform formats
http://bugzilla.mozilla.org/show_bug.cgi?id=7067

#17048 - Roaming access - keep bookmarks/cookies/history/etc in a central repository
http://bugzilla.mozilla.org/show_bug.cgi?id=17048

#17457 - Need formalized way to "import" a profile
http://bugzilla.mozilla.org/show_bug.cgi?id=17457

Bug# 65960 - Set user profile location via registry key (network drive)
http://bugzilla.mozilla.org/show_bug.cgi?id=65960

Bug# 124048 - Roaming - Funding - Sync during runtime
http://bugzilla.mozilla.org/show_bug.cgi?id=124048
You can already set each user's cache directory to a specific location, such as
c:\temp or whatever. You can set it for each user in Edit | Preferences, or set
"browser.cache.disk.parent_directory" in each user's "user.js" file in their
profile directory (creating it if necessary), or perhaps even in the all.js file
in the Mozilla program directory.
Keywords: mozilla1.3
Another work around, again in all.js (I had to create this file for 1.7.2 on Win32)

profile.migration_behavior
 0: default behavior, i.e. use NS_APP_USER_PROFILES_ROOT_DIR
 1: create new directory, based on NS4.x dir

This is what I used. In my case \\server\share\netscape\users\user was migrated
to \\server\share\netscape\users\Profiles\user\<salted>.slt
Not perfect, but good enough.

 2: Use "profile.migration_directory" if empty, fall back to default behaviour
if not. I'll leave this to someone who is more of a perfectionist than myself.
QA Contact: doronr → profile-migration
This bug is filed in a bugzilla component related to pre-Firefox code which no longer exists. I believe it is no longer relevant and I am therefore closing it INCOMPLETE.

If you believe that this bug is still valid and needs to be fixed, please reopen it and move it to the Toolkit:Startup and Profile System product/component.
No longer blocks: 1243899
Status: ASSIGNED → RESOLVED
Closed: 8 years ago
Resolution: --- → INCOMPLETE
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.