Closed Bug 528954 Opened 15 years ago Closed 15 years ago

As a symlink (created with mklink), user.js ignored on Windows due to nsIFile::fileSize being 0 for the symlink

Categories

(Core :: Preferences: Backend, defect)

x86_64
Windows 7
defect
Not set
normal

Tracking

()

RESOLVED WORKSFORME

People

(Reporter: jaraco, Unassigned)

References

Details

User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.5) Gecko/20091102 Firefox/3.5.5 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.5) Gecko/20091102 Firefox/3.5.5 Quick background: I'd like to store my firefox customizations in a source code repository so I can keep it synced between machines and easily create new machines. I know there are probable add-ons to do this, but I'd prefer to control where the configuration is stored. So I create user.js and add it to my source code repository, then create a symlink to it from my profile directory. For example cmd /c mklink %appdata%\mozilla\firefox\Profiles\abcdefgh.default\user.js %userprofile%\config\firefox\user.js This creates the symlink in the profile directory and I have confirmed that I can read and edit the file as if it were in the firefox profiles directory. However, when I start Firefox, it appears to ignore the user.js file. If instead I copy the file instead of creating a symlink, it parses the file and overrides the settings as expected. I followed the same process on my Ubuntu 9.04 box. I checked out the file from the source code repository and symlinked it. For example, sh -c ln -s ~/config/firefox/user.js ~/.mozilla/firefox/abcd1234.default/user.js I then start Firefox and it parses the file just fine. Therefore, I conclude that Mozilla (or possibly just Firefox) is not honoring symlinks in Windows (perhaps just for user.js, maybe for other files). Reproducible: Always Steps to Reproduce: 1. Create c:\user.js with a single setting override. 2. Confirm that the setting is not already set in about:config. Stop firefox. 3. Create a symlink from the default profile user.js to c:\user.js. 4. Start firefox and confirm the custom setting has not taken effect. 5. Stop firefox. Delete the symlink. Copy the file to the profile directory. 6. Start firefox and confirm the custom setting has taken effect. Expected Results: Firefox should not treat symlinks differently in Windows than in Unix. In particular, it should honor the symlinked files in the profile.
This issue continues to be a problem on Firefox 3.6. Can someone suggest where the code relating to handling of user.js on Windows might be found? I'd be happy to review it and seek to develop a remedial patch.
Process Monitor may help your first diagnosis. > http://technet.microsoft.com/en-us/sysinternals/bb896645.aspx > Filter: If Path contains user.js, Include What kind of call is done by Fx? What return code is returned by OS?
I see this in Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.5pre) Gecko/20100502 Namoroka/3.6.5pre, but It works fine in Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.3a5pre) Gecko/20100502 Minefield/3.7a5pre Looks like this was inadvertently fixed in bug 507288 (http://hg.mozilla.org/mozilla-central/diff/0e8fae2dd64c/modules/libpref/src/nsPrefService.cpp makes us use nsIInputStream::Available() instead of nsIFile's fileSize; the latter returns 0 instead of the correct file size). The code you asked for is at http://mxr.mozilla.org/mozilla-central/source/modules/libpref/src/nsPrefService.cpp#290, which can be found by grepping the source for "user.js": http://mxr.mozilla.org/mozilla-central/find?text=user.js&kind=text&string= I don't think you'll be able to convince the drivers to include this change in a point release (3.6.x), so resolving as WFM, since it's fixed in the development builds.
Status: UNCONFIRMED → RESOLVED
Closed: 15 years ago
Component: General → Preferences: Backend
Depends on: 507288
QA Contact: general → preferences-backend
Resolution: --- → WORKSFORME
Summary: As a symlink, user.js ignored on Windows → As a symlink (created with mklink), user.js ignored on Windows due to nsIFile::fileSize being 0 for the symlink
You need to log in before you can comment on or make changes to this bug.