Closed Bug 157662 Opened 23 years ago Closed 16 years ago

Use relative, dynamically resolveable paths in profile registry.

Categories

(Core Graveyard :: Profile: BackEnd, defect)

Product:
Core Graveyard
Component:
Profile: BackEnd
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED WORKSFORME

People

(Reporter: batcat, Unassigned)

References

Details

Aplication Data folder is 'tracked' by Windows so if it gets -MOVED- for any Windoz still knows where it is and uses it there. The main Mozilla exe does not do this, rather it must use an absolute path of 'c:\(windir)\Application Data\Mozilla\' I moved my 'Application Data' folder off C:\windowz to D:\Local Data\Application Data' Reboot Windows and Mozilla has lost its mind, er, lost track of any/all users. There are other folders that Windows 'tracks', like 'My Documents'. Allowing those to be moved off of C:\ and onto something like D:\ or even a 'mapped network' drive. (that would allow for common projects) Its not realy a 'relative path' but more of a 'soft configuration path'. Duplication EASY. (and put it back!!) Simply MOVE the 'Application Data' folder elsewhere. (drag the folder to another folder or drive and hold the SHIFT-key before dropping it) Everything is removed from the Windowz folder. Peak in the new location to see what other 'App's data' is in it too.. so you can try them too. Re-Boot, try Mozilla (lost eveything) and another App' or two you noticed were in the 'Application Data" folder. Most will work still, some like Mozilla will be brain dead. You can MOVE the folder back and all will returned to normal. You will notice that icons on the Quick-Launch bar will be gone immidatly when you do the MOVE but return when you reboot, nothing lost. (Doesn't happen on OS's above 98se) -------- Why would anyone want to do this? (are you kidding? every one -should-!) Saving any 'random data' to boot drives is asking for trouble. With local cofigures, buffers and cache data OFF BOOT drives the system itself stays untouched. We re-do boot drive images weekly, data configures/data stay untouched. What am I going on about? The Unix/Linux world -knows- you don't allow random data and stuff anywhere they are not suposed to be! LOL I just learned recently that Microsoft 'wants' games to save the 'save-game-data' to 'My Documents' ugh. ..anyway. thanx for your ear(s). Should be a _relatively_ easy one to fix. Opps I sent a blank bugger.. Dug/BatCat
*** Bug 157654 has been marked as a duplicate of this bug. ***
Have you also changed the registry settings for the new location ? There is no soft-link or something on Fat32 or NTFS (NTFS can mount inside the FS) Linux has real symlinks... And if you do this mozilla will find the folder again but mailnews will not work. (but that's known)
Assignee: law → Matti
Component: File Handling → Browser-General
QA Contact: sairuh → asa
nonono... I did nothing but drag-drop folder in MOVE mode with the SHIFT key.. Try it on any -dumb- folder. original is deleted and copy is at desination. The trick is Windows keeps track of it, and a few other folders. You can't delete them either. but you can MOVE'em. Here's an example.. You can drag items(shortcuts or folders) around inside the Start Menu. But if you unistall the program those moved items 'go away' too. The install log file does not know you moved them either. Windows tracks them. The main system folders that are coloured differantly, like locked, can be MOVED. Sure easy to copy them, but you can't DELETE the original. (If you realy want you -could- tweak registry but that not whats happening here) Consider Windows has a variable called 'WinBootDir' (example, I don't know what its realy called) You could load '$WinBootDir\rundll32 something' Mine personal machine has 'c:\windowz'. Notice the 'z'. A program loading 'c:\windows\data.bmp' would fail. Lots of folders are locked/tracked. 'My Documents' is another. Mine is on d: so the Windows equivilant would be something like '$MyDocDir'. So the Windowz\Application Data folder would have something like '$MyAppData'. So Mozilla would be using '$WinBootDir\Application Data\Mozilla\..etc'. Instead it should be using $MyAppData\Mozilla\..etc. Windowz would be keepiling all this stuff in the registry somewhere. If you start draging stuff around in your Start Menu the reg' files start to grow, rather quickly too. get it? Need late evenning chat? irc somewhere? (wave)
profiles.
Assignee: Matti → ccarlen
Status: UNCONFIRMED → NEW
Component: Browser-General → Profile Manager BackEnd
Ever confirmed: true
QA Contact: asa → ktrina
what have you in the registry : open regedit and this key: HKey_Current_User\Software\Microsoft\Windows\CurrentVersion\Explorer\Shell Folders\ Appdata >So Mozilla would be using '$WinBootDir\Application Data\Mozilla\ That wouldn't work with my german OS because Application Data is "Anwendungsdatan". Mozilla use %appdata% under win2k/xp (echo %appdata%)
> I moved my 'Application Data' folder off C:\windowz to D:\Local Data\Application Data' When you did this, can you be more specific about the problem than "and Mozilla has lost its mind" ;-) I suspect what happens is that the profile registry is found (becasue we use Win32 API to find "Application Data") but that none of the profiles in the registry were found. Is this what happened? We do have a means for specifying a path relative to any known location (known to nsIDirectoryService anyway). If the profile was stored inside "Application Data", we could store a relative path which was relative to that. The "relativeTo" dir is looked up at runtime so should be moveable. Of course, if you created the profile in some random location on your machine, this wouldn't work.
Resummarizing.
Status: NEW → ASSIGNED
Summary: Absolute rather than SOFT(relative?) Path.. → Use relative, dynamically resolveable paths in profile registry.
Target Milestone: --- → mozilla1.2alpha
I am starting find the bug reporting thing a tad overwhelming. Seems it would be easier to reply in email, quotes and comments than this form page.. Comment #5 From Matthias......... > what have you in the registry : > HKey_Current_User\Software\Microsoft\Windows\CurrentVersion\Explorer\Shell\Folders\ Appdata Not relavant anymore as I moved it back. Din't want to lose my mails and such. > > So Mozilla would be using '$WinBootDir\Application Data\Mozilla\ > That wouldn't work with my german OS because Application Data is "Anwendungsdatan". > Mozilla use %appdata% under win2k/xp (echo %appdata%) This is cool as it would work out. Seems to me you should have a better idea of what it is doing than I, as I had never considered localization of this stuff. Man, it must be a nightmare. There must be a point early where it combines the paths and then does not look again. Asumes its absolute and not going to change. Comment #6 From Conrad > > I moved my 'Application Data' folder off C:\windowz to D:\Local Data\Application Data' > When you did this, can you be more specific about the problem than "and Mozilla > has lost its mind" ;-) I suspect what happens is that the profile registry is > found (becasue we use Win32 API to find "Application Data") but that none of > the profiles in the registry were found. Is this what happened? Yep, Mozzila was basicaly blank and wanted me to create a user from scratch. > We do have a means for specifying a path relative to any known location (known > to nsIDirectoryService anyway). If the profile was stored inside "Application > Data", we could store a relative path which was relative to that. The > "relativeTo" dir is looked up at runtime so should be moveable. Of course, if > you created the profile in some random location on your machine, this wouldn't > work. No I let Mozilla do what it wanted, I did not create any user elsewhere. All I wanted to do was get more 'configuration data' off my boot drive and make it easier to zip/backup. Somehow I had never noticed the AppData' folder. Lots of stuff in there. It might be building the path to it at install time on win98se and not re-creating it at run time. Does this make sence?
*** Bug 160512 has been marked as a duplicate of this bug. ***
-> 1.3a
Target Milestone: mozilla1.2alpha → mozilla1.3alpha
*** Bug 167917 has been marked as a duplicate of this bug. ***
OS: Windows 98 → All
Hardware: PC → All
*** Bug 184395 has been marked as a duplicate of this bug. ***
Mass move of 1.3a bugs -> 1.4a.
Target Milestone: mozilla1.3alpha → mozilla1.4alpha
*** Bug 165841 has been marked as a duplicate of this bug. ***
-> 1.5a, along with bug 174522 which will fix this as well.
Depends on: 174522
Target Milestone: mozilla1.4alpha → mozilla1.5alpha
*** Bug 209490 has been marked as a duplicate of this bug. ***
The fact mozilla uses a hard coded value of "/home/<user>" is on unix is equally unfortunate since the stanards at my last two unix companies were /home/<server>/<user> and /usr/people/<user>. Not too hard to work around on unix with softlinks, but Windows isn't so consistent on how <file>.lnk is handled or respected. It's perfectly valid to have foo.lnk -> <somplace else>, and you see the litte link sign before "foo" "^foo" and in the same directory have a real file or directory named foo. The OS, can't reliably resolve such 'lnk' kludges. I came at this problem from a slightly different angle. Administrators are supposed to be able to move user-profile directories -- happens alot -- especially if you have roaming profiles. The place where it roams to on a particular workstation, I don't believe, has to be the same. All of the user's data is relative to %USERPROFILE%. Also -- another issue -- for users that go from single user-machines to multi user machines, the main user's directory is copied to the new location. Mozilla, not using relative paths will still put it's data in the old location under C:\windows\application data. But the user's personal data, which may later be saved and copied is all supposed to be under C:\windows\profiles\<user> (under win98 and maybe ME). If they move their stuff to a WinNT, it's a different path and winXP uses "Documents and settings" (finally moving it out from the system dir), though on my machine Documents and settings got changed to be named "home". I run cygwin -- and it was easier to 1 home directory/user. As it stands, I'm not quite sure how to migrate the mozilla data from its old location since it stores stuff in its own registry.dat file which I don't have an editor/fileformat for. You can see Bug 209490 (http://bugzilla.mozilla.org/show_bug.cgi?id=209490) for a complete decription of the problem. Thanks, -linda
*** Bug 139926 has been marked as a duplicate of this bug. ***
*** Bug 220044 has been marked as a duplicate of this bug. ***
Blocks: 211628
(In reply to comment #17) > I came at this problem from a slightly different angle. Administrators are > supposed to be able to move user-profile directories -- happens alot -- > especially if you have roaming profiles. The place where it roams to on a > particular workstation, I don't believe, has to be the same. > All of the user's data is relative to %USERPROFILE%. Just to add to all of this... Under Windows, no active change to configuration is required ata ll to trigger this bug. If roaming profiles are in use, your local profile can be copied to different places locally due to...frankly, I don't know due to what. Somtimes at work my roaming profile mounts to c:\Application Data\<user>, sometimes to ...\<user>.<domain>, and sometimes to something like .../<user>.<domain>.NNN. These do not reflect any changes by me or the admin. It simply means one day you log in and Mozilla has lost your profile.
*** Bug 245010 has been marked as a duplicate of this bug. ***
*** Bug 238726 has been marked as a duplicate of this bug. ***
*** Bug 284413 has been marked as a duplicate of this bug. ***
*** Bug 287561 has been marked as a duplicate of this bug. ***
This is a problem in our corp environment as we're using user folder redirection. e.g. c:\users\john.doe then becomes a UNC path e.g. \\contoso.local\uds\settings\john.doe -- then the XP/Vista offline files feature can cache the UNC path locally transparently. A profile can change from being local to being redirected to a UNC path Because FF stores the absolute path inside profile data this really breaks a users setup when migrating to/from this scenario. FF should be using the %APPDATA% path prefix and not have any embedded absolute paths. Without this, FireFox is not platform compliant and thus deprecated in corp environments which use this feature.
Within the profile there should be only relative paths in usage. So you talk about the paths which are written to the profiles.ini?
Assignee: ccarlen → nobody
Status: ASSIGNED → NEW
QA Contact: ktrina → profile-manager-backend
Target Milestone: mozilla1.5alpha → ---
Look in prefs.js, the download directory is absolute, so are entries in extensions.ini. They should be using %APPDATA% as the prefix neither the UNC or the local drive path.
The download dir has nothing to do with a non-working profile because of using absolute paths. It will updated depending on the prefs (same folder/ask me) the user has set. Shawn, the extensions.ini stores the paths as complex values, right? How can someone easily convert it to a human-readable path?
(In reply to comment #28) > Shawn, the extensions.ini stores the paths as complex values, right? How can > someone easily convert it to a human-readable path? Create an nsIFile with it, and get the path out of that?
extensions.ini is rebuilt when the profile directory changes... this WFM with windows roaming profiles for example.
Status: NEW → RESOLVED
Closed: 16 years ago
Resolution: --- → WORKSFORME
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.