User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:188.8.131.52) Gecko/20060426 Firefox/184.108.40.206 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:220.127.116.11) Gecko/20060426 Firefox/18.104.22.168 Using local profiles, Firefox works jsut fine. Though, there is a problem at my university: they are using a server to store user's data so the path for the profile-directory is "translated" into a network-path. There is no problem with that, but while talking to a laboratory engineer we (he and I) discovered that Firefox uses a method of Windows' API to get the path for application data (on 2000 and XP it's "C:\Documents and Settings\USERNAME\Application Data\Mozilla\Firefox"). This method does not return the correct path so he played a bit around with the Win API and finally got a solution: instead of using the Win API-call for getting the path to the "Application Data"-directory, he suggests to get the environment-variable. As I don't know much about C++ (only know a little bit of C and right now, I'm learning Java), I hope that my suggestions and hints are correct. If you need to know more about his thoughts regarding the cause and the solution, please let me know. He won't answer as he's to busy, but I'll do. :) Regards, Martin.. :) Reproducible: Always
Summary: FF gets wrong directory → FF gets wrong "Application Data"-directory
According to bug 162025: Firefox should handle UNC path for profile. If you confirmed that win API is wrong on your machine, perhaps something is wrong on that machine (bad settings or so)?
(In reply to comment #1) > According to bug 162025: Firefox should handle UNC path for profile. > If you confirmed that win API is wrong on your machine, perhaps something is > wrong on that machine (bad settings or so)? No, the problem is the Win API itself, because Windows' method returns the wrong path. This happens on a Windows XP Professional- and Windows 2003 Server-system (first = my computer at the university, second = laboratory engineer's notebook). Additionally, I can tell that the engineer told me to state the following: the fix could be done in the header-file of, well, I've forgotten the filename.. :( Anyway, it was the header-file where "GetUserDataDirectory" or something like that and the code took only 3 lines and the 3 lines after that looked similiar..
OK, here's some more information: Firefox uses SHGetSpecialFolderLocation(NULL, CSIDL_APPDATA, ...), but CSIDL_APPDATA returns the same as CSIDL_LOCAL_APPDATA, but this is not the same as %APPDATA% (in our case an unc path). The problem occurs in GetShellFolderPath() (nsXREDirProvider.cpp), which is called by GetUserAppDataDirectory (nsXREDirProvider.h). GetUserAppDataDirectory should not call GetShellFolderPath(), but instead read the environment variable APPDATA. Regards, Martin.. :)
(In reply to comment #3) > OK, here's some more information: Martin, I think this is a WONTFIX and that your computer settings are wrong, but we will see what a developer thinks. In the meantime, perhaps you should try to find why win API give wrong results in your case (MSDN, ...)?
From MSDN: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/shellcc/platform/shell/reference/functions/shgetfolderlocation.asp "The SHGetFolderLocation, SHGetFolderPath, SHGetSpecialFolderLocation, and SHGetSpecialFolderPath functions are the preferred ways to obtain handles to folders. Functions such as ExpandEnvironmentStrings that use the environment variable names directly, in the form %VariableName%, may not be reliable."
(In reply to comment #5) > From MSDN: > http://msdn.microsoft.com/library/default.asp?url=/library/en-us/shellcc/platform/shell/reference/functions/shgetfolderlocation.asp > > "The SHGetFolderLocation, SHGetFolderPath, SHGetSpecialFolderLocation, and > SHGetSpecialFolderPath functions are the preferred ways to obtain handles to > folders. Functions such as ExpandEnvironmentStrings that use the environment > variable names directly, in the form %VariableName%, may not be reliable." > In fact, the API is not reliable as you can see when you create a little program which returns the path given by the API-call(s) and when you query the environment-variable you'll get the right path.. It can't be a WONTFIX due to it's *not* depending on my computer configuration. Instead, all computers at the university show this bug..
If it's a bug in the Windows API, it's still a WONTFIX since MS would need to it at their end. But i also doubt it's a bug in the Windows API, i rather suspect your university uses a not-so-common method to store user profiles on the server. Do they use the roaming profiles function in Windows or how do they make that work? Setting the env var APPDATA to something is not a clean way to get server stored profiles.
(In reply to comment #7) > If it's a bug in the Windows API, it's still a WONTFIX since MS would need to > it at their end. But i also doubt it's a bug in the Windows API, i rather > suspect your university uses a not-so-common method to store user profiles on > the server. Do they use the roaming profiles function in Windows or how do they > make that work? Setting the env var APPDATA to something is not a clean way to > get server stored profiles. As we both know quite well, there won't be a fix in the Windows API so it would be great if the Firefox-developers would care about this and do a workaround to fix that. I've talked to the guy responsible for this problem and he told me that they're not setting the APPDATA-environment variable. Instead, he said, they're using "Folder Redirection" included in the "Group Policy Management" of Active Directory. There you can find a property called "root directory" and that is set to "\\OURSERVER\USERNAME". Regarding if this method is common or not, it's a very efficient method, IMHO at least..
Well the fact that bugs like bug 291033 get fixed suggests that it does work correctly for some people. If you think this is a bug in Win32, it would surely come up somewhere else. Could you provide a link to description/discussion of that win32 bug? A quick search didn't find anything on the topic.
Component: OS Integration → XRE Startup
Product: Firefox → Toolkit
QA Contact: os.integration → xre.startup
Version: 1.5.0.x Branch → Trunk
Status: UNCONFIRMED → RESOLVED
Last Resolved: 12 years ago
Resolution: --- → WONTFIX
Component: XRE Startup → Startup and Profile System
QA Contact: xre.startup → startup
Well, due to some strange things happened, I only received a mail for this bug about some hours ago.. So, since I'm not part of that university anymore, I can't provide information regarding their IT-infrastructure and/or settings..
You need to log in before you can comment on or make changes to this bug.