Closed Bug 44071 Opened 25 years ago Closed 24 years ago

"users50" should be "profiles"

Categories

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

Product:
Core Graveyard
Component:
Profile: BackEnd
Type:
defect

Tracking

(Not tracked)

Status:
VERIFIED FIXED
Milestone:
mozilla0.9

People

(Reporter: bugzilla, Assigned: ccarlen)

References

Details

Attachments

(5 files)

Diff file to fix "Users50" -> "Profiles"
3.84 KB, patch
Details | Diff | Splinter Review
New and improved diff to fix all references to Users -> Profiles
6.26 KB, patch
Details | Diff | Splinter Review
Diff to fix the creation of new profiles to "Profiles" instead of "Users50"
771 bytes, patch
Details | Diff | Splinter Review
New and updated diff!
6.88 KB, patch
Details | Diff | Splinter Review
What the equivalent folder looks like in Outlook Express
14.75 KB, image/gif
Details
I've never understood why the user profile directroy is called users50. Why depend on a version number in the profile directory name? Now that Netscape's next version is gonna be called Netscape 6 and Mozilla's version perhaps are gonna be 1.0 why not remove the "50" from the profile directory name?
reassiging to racham.
Assignee: putterman → racham
Well, in the beginning netscape and mozilla shared the same directory, and netscape used users, and mozilla used users50, and mozilla looked upon it, and said that it was good. Now the lands have been seperated, and the need for a 50 nolonger exist.
When I tried Netscape PR-1 on Win 98 the default install was to the Netscape folder. users and users50 are in the same folder. If users was used it could cause Netscape 4.x profiles to be overwritten with the Netscape builds, and also with the Mozilla builds if the user decided to install in the netscape folder instead of the default folder. It would be a better idea to change from users50 to profiles.
Good point about the "users" -> "profiles", since this is also what's called in the application.
Summary: "users50" should be "users" → "users50" should be "profiles"
I brought up this issue already...but with a different name (Users60 : bug 30421). However, 'profiles' sounds better than that. Accepting the bug. Though this is an easy fix, it will not be in for beta2. An issue to be addressed in beta3.
Status: NEW → ASSIGNED
Keywords: nsbeta3
Target Milestone: --- → M18
*** Bug 30421 has been marked as a duplicate of this bug. ***
*** Bug 45191 has been marked as a duplicate of this bug. ***
Keywords: patch
patch looks good. We should run some tests and push it.
Component: Profile Manager BackEnd → ActiveX Wrapper
Why is this changed into Component ActiveX Wrapper????
Component: ActiveX Wrapper → Profile Manager BackEnd
In previous updates, I guess someone just modified/chose the component to ActiveXWrapper incorrectly....! Thanks for noticing and changing that.
Any chance this will get checked in?
If someone reviews it, I'll check it in
racham: Could you please review...
Keywords: review
http://lxr.mozilla.org/seamonkey/search?string=users5 has couple of more places that uses Users50 name in comments and code. Adding Conrad to the cc list. We have appfilelocprovider in the modules also. Probably it is already announced somewhere that whether are not applocprovider under is going to used in the mozilla or not. Please make sure all the callers are taken care of. I knoe this is a simple fix. But, do test it to make sure that no undesirable side-effects are seen. r=racham After you get the check-in approval, please make sure that you give a heads to people as many sofar have been tuned to Users50 may get surprised otherwise. You should also tell them that their Users50 will also be valid as long as they don't delete the registry.
modules/appfilelocprovider/ is currently used by SeaMonkey. Ignore the one in xpfe. I had done a CVS remove on that one and it must not have worked :-/ I'll take care of that. nsFileLocations.cpp is going to be retired in the next few days - as soon as all refs to it are gone.
Blake: your patch changes two AppendRelativePath() places in each file, LXR is currently showing three that need changing so you need to add one before we can approve this patch.
I didn't write this patch.
Is this bug valid anymore? The latest posting about the fix for bug 6464 didn't mention "Users50" at all, so maybe this is obsolete.
Dan this bug is valid. Fix to 6464 merely changed the location where it lives. As I mentioned earlier, we need nsbeta3+ to get the required name change checked in. Adding Steve to the cc list.
We do not need nsbeta3+ to check this in. The patch is from a mozilla contributor. All that's needed is review and approval from brendan or waterson. Someone review, and then we'll get approval.
gemal, Please note the update made by Conrad Carlen. Patch contains modifications to mozilla/xpfe/appfilelocprovider/src/nsAppFileLocationProvider.cpp where as his update mentions that file that need to be really modified is mozilla/modules/appfilelocprovider/src/nsAppFileLocationProvider.cpp. Please update your patch and do another lxr query for Users50. Looks like patch is also missing User50->Profiles update for XP_OS2. I know this patch has been posted a while ago and hence little out-of-date. So, please update it and test it. thanks.
That's silly, Mozilla folks don't need nsbeta3+ they just need approval from Brendan@mozilla.org or waterson@mozilla.org. But we need a slight correction to Henrik's patch before we can check it in, it appears there have been a couple more 'user50' places added since he made it.
Excuse me for saying what had already been said.
Looks good to me, r=dveditz. Who's going to check this in? Bhuvan? Or should I?
trying to pop this bug back to the living. Would be nice to have this before m18.
yeps... someone please check in...
If this is truly not going through mozilla approval, then it's minus.
Whiteboard: [nsbeta3-]
any chance of getting this for nsbeta3? I think that it looks more professional having /profiles/ rather than /users50/ for netscape releases.
It's too late to get this in for beta3. It cannot be claimed to meet any of the P1, P2, or even P3 criteria since no harm is done to the user in any way. We're too close to the end of beta3 to take this on the basis of low risk either.
based on selmer's comments, adding rtm keyword. m19 milestone perhaps? (which should coincide with rtm)
Keywords: rtm
*** Bug 54130 has been marked as a duplicate of this bug. ***
I'm sorry if my comment mislead you. As I said prior to minusing this for beta3, if you're doing this under the auspices of Mozilla you need to use the Mozilla process to get it checked in. We won't take this fix for RTM.
Whiteboard: [nsbeta3-] → [nsbeta3-][rtm-]
selmer - ah, ok. Just thought that netscape would love to get tid of users50 as well.
"users50" in Netscape 6 looks kind of uncool!
I would love to have had this fixed in our release. It didn't happen in the proper timeframe, now it's too late for this type of fix. Sure, it's uncool. The average user is never going to know that unless you personally tell them all :-)
*** Bug 56497 has been marked as a duplicate of this bug. ***
Changing this without regard to the past would be trivially easy (one line in one file). Problem is, many users have profiles which are now in "Users 50." In order to be compatible, we would have to merge that dir into a new dir called "profiles" and update the registry entries. This is non-trivial and I doubt it's worth it.
could we not rename users50 to profile somehow? Natrually, we would have to check if it already exists and then we would need to merge etc. Probably would stop from getting into rtm
Like I said, it's not just a matter of renaming the directory. The registry entries would have to be updated. It's do-able but scary at this point.
Whatever you're thinking of doing here can only go on the trunk. This change isn't making the RTM.
Doing a mass reassign to Conrad Carlen. Conrad is going address all current and upcoming profile manager issues. Please do not hesitate to involve me in any of the issues.
Assignee: racham → ccarlen
Status: ASSIGNED → NEW
We could just change the name of new profile dirs to be created. Like I said, a 1-liner. Moving existing profiles from "users50" to "profiles" would be more trouble than worth.
Status: NEW → ASSIGNED
Target Milestone: M18 → mozilla0.9
Creating new profiles in "profiles" is a good idea!
nominating for nsbeta1 and adding mozilla0.9 keyword for completeness
Keywords: mozilla0.9, nsbeta1
Keywords: mozilla0.9, nsbeta3, rtm
Whiteboard: [nsbeta3-][rtm-]
*** Bug 64655 has been marked as a duplicate of this bug. ***
Wouldn't it be better if we used the name of the distribution (along with major version) as the profile directory?? eg. Netscape6, Mozilla1, Beonex0 etc. That way, incompatabilities between distributions and major versions of distributions can be avoided, preventing possibly corruption and maybe helping security issues. Also CC'ing Ben Bucksch as he might find this interesting
I think is really bad. If there should be any info about the profile the info should be inside the registry.dat file and not inside a directory name.
Paul Gregg, the folder which "users50" resides in is called "Mozilla", which is hardcoded :-(. Bug 58327 is about changing that. I agree that adding version numbers should be in the registry, not profile dir. Is the version number there currently? If not, is there a bug filed? If not, can somebody do that, please?
Conrad: Changing the names of newly created profiledirs to "profile" instead of "users50" would be a great start. What's needed?
i'm confused. If there is any profile versioning, it should be in the prefs.js file so that a new browser can check to see that it can safely load the profile. I often transfer just my profile and not my registry [mostly because i run many operating systems and only install once].
Henrik: just changing this line of code: http://lxr.mozilla.org/seamonkey/source/xpcom/io/nsAppFileLocationProvider.cpp#352 timeless: There isn't any profile versioning because there is no single thing to "version." The only file which profile directly reads and writes is the app registry. All the other files in a profile dir are read/written by all sorts of different components. That said, we should strive for backward compatibility in all these files and avoid the need for versioning in the first place.
timeless, what if prefs.js changed? It is part of the profile, while the version of the profile is metadata of the profile. conrad, sure we should aim for backwards compatibility. Nevertheless, we are far frmo it, and even if we are there, there are always reasons to make inkompatible changes in major revisions of the software. IMO, it is wise to add the major version number of the software that created or last successfully used the profile. In case find out later that we run into troubles, our lives will be at least a bit easier, if we have that info unambiguously.
<OFFTOPIC> <q src=benb>timeless, what if prefs.js changed?</q> that's fine. <q src=benb>It is part of the profile, while the version of the profile is metadata of the profile.</q> that doesn't make any sense to me. i'm under the impression that we can know the newest "known" version that handles a prefs file w/o complaining and also the oldest version. the profile itself shouldn't know or care about versions. Either your app can handle the profile or it can't. appQ.exe [based on 0.8] gets a list of profiles A[prefs.js]: compat=0.7; newest=0.7 {\\.\users\old} B[prefs.js]: compat=0.7; newest=0.8 {\\.\users\current} C[prefs.js]: compat=0.9; newest=0.9 {\\.\users\new} D[prefs.js]: compat=0.6; newest=0.6 {\\.\users\deprecated} E[prefs.js]: compat=0.8; newest=0.8 {\\.\users\fresh} A is displayed with an upgrade warning. B is displayed. C is listed and marked as incompatible [too new] D is listed and marked as incompatible [too old] E is not listed because it isn't registered on \\confused User shares out \users50 as \\confused\users User runs AppR.exe [based on 0.9.1] on \\fresh which has never had mozilla. AppR can't find any profiles and gives the profile manager dialog [it isn't mozilla or netscape and this is a design decission]. User selects browse and points to \\confused\users\new\prefs.js AppR recognizes the preferences as 0.9 based and registers it in the mozregistry. user runs AppS (based on 0.8 w/ pref versioning support), it finds only the 0.9 profile which it lists as incompatible. User points to \\.\users\fresh\prefs.js ; AppS registers the profile and happily runs. </OFFTOPIC> <rant>This is all stupid.</rant> We don't need to rename the profile directory. As long as users can import profiles from arbitrary paths and as long as we recognize all paths listed in the mozregistry then there is nothing wrong with changing the default profile directory for new profiles.
"users50" should automatically be renamed by mozilla. else it won't find that folder on migrated profiles..
I thought the diff I attached only affected newly created profiles? Changing all old profiles dir names is a more difficult task...
Håkan B. Waara, i think you're wrong. The mozilla registry stores profile locations. There is no need to rename the directory because the registry knows where each individual profile lives. This bug should not have required any discussion or thought for that very reason.
Yes. Profile locations are stored in the registry so Henrik's patch would not affect existing profiles at all.
could someone if knowledge in getting r and sr try to get the last patch checked in?
My only hesitation in doing this is that somebody who already has a "Users50" dir will now find a "Profiles" dir next to it, and move their profiles from Users50 -> Profiles. When that doesn't work, the pile of bugs filed will be a pain ;-) I'm half serious. Aside from that, it's a good idea.
I'm willing to relnote that. And we should have a "lost profile" dialog anyways [i don't know if we do]. I use that in nc4 whenever i need to rearrange profiles [i move them, or change drive letters, and then run netscape, it lets be browse for the correct directory]. If we don't have that dialog, please file a bug for it.
"If Profile Directory doesn't exist an error should occor": http://bugzilla.mozilla.org/show_bug.cgi?id=47023
Henrik: I marked bug 47023 a dup of bug 62418. There is already I patch on that one for the missing profile dir problem. timeless: In order to really solve the missing profile dir problem (be able to browse for it and reset the location), we need to use relative paths instead of absolute paths (as we do now on Win & Linux) in all files within the profile dir (mainly prefs) That is bug 12911.
couldn't we checkin the last patch to fix newly create profiles?
Why is it that every time this bug gets near to being checked in it gets dropped again? <sigh> Henrik, could you check your patch for sanity, please? Let's try and get reviewed, super-reviewed and in before mozilla1.0! Gerv
I have not checked it in mainly because I'm not sure how much documentation says it's in "users50", and what sort of headache it may cause for QA. Grace, what's your opinion on this? Basically, after all the discussion on this bug it boils down to this: The name "users50" would be changed to "profiles" for new profiles only - existing profiles would not be moved.
Conrad, I don't see a problem there - the path finding is so freaky and complicated already that it is nearly impossible to specify that path generally. So, Qa shoudn't have a problem, and it shouldn't appear in many docs either. If you care, just grep the Netscape docs for "users50".
Conrad, I am ok with this change. I think selmer makes point that most ordinary users don't look at this directory- they have one profile and it launches. As comment above notes, we have been through lots of changes with this component and I agree that 'profiles' as a name for the storage area for these files makes the most sense. I think we should release note for the mozilla community and when changed we should alert QA and internal testers/users, especially those who remove this directory for their testing. The amount of feedback when 'salted name' came into being is proof that 'getting the word out' is important.
Oh, you are going to hate me for this ... If we are going to finalize the folder name, can we please make it look respectable? File and folder names should use title case (e.g. "Documents and Settings", "Mozilla Preferences") -- lower case is for URLs. And people browsing their hard disks are more likely to understand what a `user profile' is than what a `profile' is, since the term `profile' is also used for other things -- on my HD, for example, I have system-related folders called `ColorSync Profiles', `Display Profiles', and `Speed Disk Profiles'. So, please "User Profiles" rather than "profiles".
mpt: You need to learn to read code :-) The patch currently calls the directory "Profiles" - in the correct title case, but without the User. I agree with you, though - now that all sensible OSes support spaces in filenames and long file names (don't they?), we should be able to call it "User Profiles" without too much trouble. Gerv
Are we sure there are no problems with "User Profiles" instead of "Profiles" ? If there's none, I'll provide a new patch...
If you use these paths in scripts or even just on the commandline, you need to escape it in some way, e.g. enclosing the whole path in "". Is the bug that didn't allow profile dir names (paths?) passed to mozilla -createprofile to contain spaces fixed at all? Anyway, this shows the subtle problems that might crop up. I don't think that "User Profiles" is so much better than "Profiles", especially considering that this dir is in a folder named after the product, e.g. the full path is something like "c:\windows\Mozilla\Profiles\mychosenusername". For me, that sounds a lot like "Display Profiles". I'm not totally against "User Profiles", but I don't think, it's such a good idea.
I'm also for "Profiles"
Gemal, you don't need to touch embedding/tests/mfcembed/winEmbedFileLocProvider.cpp. mfcEmbed is a completely separate app from mozilla, stores its profiles elsewhere, and likes its profiles where they are now.
OS/2 has a file system which does _NOT_ like long file names. Profiles is fine however nothing longer than 8 chars :) 'Mail to Profiles' is odd. I dislike it both for asthetic and technical reasons.
We already require that user profiles go on a long filename system driver due to other filenames in the user profile directory (localstore.rdf for example) That having been said, we think the best solution for these type of 8.3 issues is probably to provide some sort of #ifdef that can be set through configure. And the more we can catch as they are being created, the better off we will be in the future. I certainly don't want my OS to be responsible for shortening everyone else's names :)
those are additional bugs which someone should file and fix hopefully before mozilla 1.0 . Profiles are supposed to be portable across all platforms. note that we settled on prefs.js for all platforms ... #ifdef is really unacceptable because it breaks platform portability.
> Profiles are supposed to be portable across all platforms. note that we settled > on prefs.js for all platforms ... #ifdef is really unacceptable because it > breaks platform portability. I fully agree. No #ifdefs!
I don't think the platform portability argument holds much weight. The number of people who are going to try to use the same profile (rather than just, say, a symlink to the same bookmarks file and preferences file) on multiple OSes at once is miniscule in comparison to the number of people who are going to look in the funny folder which Mozilla has placed (without asking) inside their `Documents' folder, and get paranoid about exactly what it is that Mozilla is `profiling'. And anyway, the profiles folder is already inside a folder called `Mozilla Folder', which is created along with such items as `Mozilla Registry' and `Mozilla Versions' when Mozilla is first run. I bet those folders and files don't have the same names on other OSes.
I would really like to see this low priority bug get off the radar. If you can get the existing patch r=/sr= and checked in then please do that. Otherwise, let's admit this doesn't matter and just future it.
gemal, I give my r= to patchid=23346 - no others. As an outside contributor, if you can get a= from waterson@netscape.com or brendan@mozilla.org, I'll check it in for you.
Not sure what an outside contributor is, but he needs an sr from someone at mozilla.org/hacking/reviewers.html just like everyone else... That said, I don't see someone specifically qualified to sr this, so maybe Brendan is the best bet after all. cc'ing him
Instead of "outside contributor", I meant that the patch was submitted by one who doesn't have CVS checkin ability. This one is low priority to me and if somebody who can check it in wants it, go ahead. 'Til then, futuring.
Target Milestone: mozilla0.9 → Future
Conrad, part of module ownership is taking good patches. If the patch looks good to you (it does to me), please get it in ASAP. Don't future it, or the patch will rust and the contributor will get frustrated and stop contributing. Sorry I didn't sr=brendan@mozilla.org earlier -- I've been having dogfood mail woes (typing this into 4.61). /be
Brendan, you're right. Apologies to gemal. Now it's sr'd, I'll check it in.
Target Milestone: Future → mozilla0.9
Conrad - after you check in, you might want to make a quick post to n.p.m.seamonkey to say that this has changed; more than a few people have "Profile Nuke" scripts which this will break. Gerv
thank you Gerv, that should reduce bug reportage
Gerv, the rule is "post before a change that may affect others to warn them, and post again after check in.". I suggest you or gemal make the first post, and conrad then follows up with a quick note after checkin.
Fix checked in. It's now "Profiles" Hopefully, though not all, more people will like that.
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
has the entire patch been checked in? I only see a checkin for: mozilla/xpcom/io/nsAppFileLocationProvider.cpp
Like I said before, patchid=23346 was all that was needed so that's what I checked in.
verified on build 2001/04/18/06 Win/ 2001/04/18/09 Mac
Status: RESOLVED → VERIFIED
I don't want my old profiles under "user50" and new ones under "profiles". I have a LOT of mail in my current profile and would like to update to the new system with ALL my profiles. Is there a good method (newsgroup post, FAQ, etc) for moving my existing profiles to the new directory? I would appreciate detailed, step-by-step instructions.
Why do you care where Mozilla keeps your profiles? You can just leave it in Users50 and everything will be fine. Nothing is going to break if you leave it where it is. If you must move it, you could try creating a new one (to get the salt) with the same name and then using "copy". :-) Gerv
> Is there a good method (newsgroup post, FAQ, etc) for moving my existing > profiles to the new directory? I would appreciate detailed, step-by-step > instructions. Yes. See: n.p.m.seamonkey ("Profile dir name has changed", 4/17/01)
The method for moving our existing profile from "users50" to "Profiles" described in n.p.m.seamonkey does *NOT* work because it says to edit the registry.dat file, which isn't a pure text file. After opening it in notepad and find/replacing all "users50" with "Profiles" (editing prefs.js went OK), Mozilla opens *without ANY* profile and asks whether i want to (re-)import my old NC4 profile :( Is there a VALID description somewhere? - please.
basicly you do this: create a new profile exit mozilla copy the old profile into the new profile directory replace all references to the old profile location with the new profile location in the new profile (stuff like mail, news, prefs.js etc...) launch mozilla
Well, I tried that, but editing the *registry.dat* file ruins everything!
you dont need to touch the *registry.dat*....
I do not need to touch registry.dat? It contains the name of the profile directory *twice*. Do you mean someone put this into the file for fun? Or maybe it will repair automagically? There two entries into the binary file were the reason I did not dare change my profile directory (especially as "Profiles" is one byte longer than "Users50"). It seems from Peter's remarks that I was right :-(
Perhaps Henrik Gemal 2001-04-27 01:14's comments didn't explain the _why_ If you create a new profile (w/ a name that you are willing to tolerate, in a directory that you are willing to tolerate); quit mozilla; move the contents of the profile directory that you want to relocate into the new profile's directory, you are effectively canabalizing it. The result is that the new profile's name is now pointing to a copy [perhaps the only copy] of your old profile. The only thing is that the profile's name will be the new one and not the old one. If you then delete the old profile name in profile manager, you could repeat the process to get the corroect profile name.
I've had enough of this. For goodness sake, Peter and Jacek - where Mozilla stores your profile information is _not_ _important_. It makes no difference. Profiles in Users50 will continue to work absolutely fine. Go do something constructive! :-) Gerv
Gervase, I know they will. I know this whole problem may be spamming, but I'm not 100% sure about that and it's not me who started the thing. People were concerned about the change. Someone sent a workaround to the newsgroups wrongly stating registry.dat has to be edited. There is a good reason to worry that some people will lose a lot more time due to this misinformation. I believed it as well but did not feel enough urge to try. However, it seems some people did. Henrik, Timeless: Agreed, that solves the thing. Registry.dat need not be edited. Thanks.
I filed bug 77924 and bug 77925 to make things easier for the future. This bug is dead. If you have any questions please use the newsgroups, irc, those two bugs or some other bug to ask it.
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: