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.

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.

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..

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.

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.

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

*** 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-

*** 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?

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.

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.

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.