Closed Bug 44071 Opened 24 years ago Closed 23 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: 23 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: