Current platform(s): Clients: Windows 2000 Professional SP2; Windows XP Professional RC2 Server: Windows 2000 Server SP2 Issue: When a network administrator has enabled the redirected folders option(s) in their Windows 2000 network, Mozilla fails to write/read its current configuration correctly. Specifically, when the network admin has redirected the Application Data portion of a user's profile, Mozilla cannot resolve the redirected folder properly. Window size and position, mail client window size and position, state of the sidebar and other such information is never correctly written or read (not sure which) from the files in the redirected profile folder. Supposition: While Windows can handle redirected folders transparently, Mozilla seems to be reading the network UNC (instead of referring to the Windows system folder - Application Data, My Documents and etc.) by reference and letting Windows handle the translation of folders and the caching of files. This makes using Mozilla with a mobile computer difficult if a network administrator enables these options in Windows 2000.
Assignee: asa → pchen
Component: Browser-General → XP Apps
QA Contact: doronr → sairuh
reporter: your information isn't clear enough for me to decipher exactly what's happening (and I think I know how NT/9x work). afaik 'redirected folders' isn't a technical term, so i'll describe how mozilla works and you can tell me what you'd like to see.. mozilla uses something akin to: %USERPROFILE%\WINDOWS\mozregistry.dat %USERPROFILE%\WINDOWS\mozver.dat [probably the registry equivalents ...] to store its settings. and there's no good way to do resolved=>unresolved mappings. plus we currently have no relative path support in profiles (there are bugs for and people working on that -- specifically for the reasons alluded to here). those files (well mozregistry iirc) store [resolved] paths to various locations, so what could we do? here is what we're doing [in no particular order and w/o bug numbers - search bugzilla] * trying to make profiles support and rely on relative paths [networking:file/preferences:backend] * add a move profile option to -profilemanager [profile manager:frontend/profile manager:backend] * improve unc and registry support [networking:file] randomly giving to profilemanager, this bug is really not something we can fix now and covers too many things to be really useful -- for this i am sorry [and this is assuming i'm understanding your problem]. actually i could bug the poor guy who's working on improving the unix side of things. Before i do, i should probably ask you what sort of behavior you would expect... #1 Suppose I create a choose to create a new mozilla profile and manually browse to a directory that happens to be inside a special folder. I use mozilla a bit, and quit. Then I change one of the special things that points there. Should mozilla [magically - guess &] follow the new special route or stick w/ the path it had before? supposing it can't follow the old path, should it magically try all magic paths and prompt the end user w/ a guess, eg: Profile could not be found, but it might be living in: \\z\q\random\profile\foobarza.slt Mozilla profiles are hidden below one level of confusion as a faux privacy protection measure, so if the last bit doesn't sound familiar, don't worry too much about it. <that's it> <browse...> <cancel> 1. would a dialog like that freak you out? 2. would a dialog like that freak your end users out? [if you say no here, most of your other answers will be treated w/ some skepticism by some of the UI designers who contribute to mozilla's ui] 3. should we do it anyways? [their answer is probably 'no - are you crazy' - cc to be sure ;-)] #2, what should mozilla favor for guessing relocation? Environment variables HOME HOMEPATH USERPROFILE APPDATA ~ any of the above + Application Data registry settings: AppData [random] windows api calls fwiw, i can't even find the documentation about %USERPROFILE%\WINDOWS it's probably near terminal services protection of the windows dir, but it's late...
Assignee: pchen → ccarlen
Component: XP Apps → Profile Manager BackEnd
QA Contact: sairuh → gbush
firstname.lastname@example.org: could you respond to timeless's questions?
Marking these all WORKSFORME sorry about lack of response but were very overloaded here. Only reopen the bug if you can reproduce with the following steps: 1) Download the latest nightly (or 0.9.6 which should be out RSN) 2) Create a new profile 3) test the bug again If it still occurs go ahead and reopen the bug. Again sorry about no response were quite overloaded here and understaffed.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → WORKSFORME
Status: RESOLVED → UNCONFIRMED
Resolution: WORKSFORME → ---
INVALID through lack of info. Reporter, reopen if you can answer timeless' questions.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 17 years ago → 17 years ago
Resolution: --- → INVALID
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.