User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8) Gecko/20051111 Firefox/1.5 Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8) Gecko/20051111 Firefox/1.5 Most text editors will save a file by either: - writing out a new copy, then renaming it over top of the old one; or - renaming the old file to a backup name, then writing out a new copy In either case, the name now addresses a new inode, and this seems to make mozilla sad on OS X. If I "reload", it claims that the file is not found. If I go to the URL bar and press enter, it finds it back again. If I go "Back" then "Forward" then "Reload", it works properly. This would seem to suggest that something is being cached that gets used during Reload, but discarded during Back/Forward or using the URL bar. It doesn't always happen -- for example, if I try it on the first local page I visit, it doesn't seem to reproduce. But if I click a link to another local page, replacing that second page will reproduce. Reproducible: Always Steps to Reproduce: 1. Create two local html files; say, one.html with an href to two.html 2. Load one.html 3. Click the link to two.html 4. Rename a file over top of two.html, or save it in vi 5. Press "Reload"
> In either case, the name now addresses a new inode, and this seems to make > mozilla sad on OS X. To be clear, Phil means "make Firefox sad". He's just all old-school.
This blocks developers working on appple filesystem. Tested with and confirmed with Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9b3pre) Gecko/2007121804 Minefield/3.0b3pre
Status: UNCONFIRMED → NEW
Ever confirmed: true
Actually the reproduce steps in bug 311382 is very nice, sorry marked dup of this. Basically reduced testcase: * open a file:// file * vi it, save it. * click reload -> file not found.
This is apparently not a regression, but it's really, really annoying for any web developer working from local disk. I bet the fix isn't hard, just looks like noone has done any analysis on it yet. Prematurely marking wanted-1.9.0.x, because blocking-1.9+ is kind of iffy, but we should fix it soon.
My suspicion is that this is related to the caching that nsLocalFileMac does, and which we don't invalidate when reloading the file URL. Not sure if we get the right notification in the nsFileURL code, but if we do we could just create a new nsILocalFile on reload and probably win.
Flags: blocking1.9? → wanted-next+
Duplicate of this bug: 455428
No longer minor I don't think -- it crops up way too often.
Severity: minor → major
Created attachment 339157 [details] [diff] [review] fix v1.0 So this is really a dupe of bug 307815, which I filed years ago. Our stat caches are egregiously incorrect and they need to go away. That's the real fix for this. I'll have to re-assess the feasibility of that in terms of perf, but my personal opinion is that we should kill them off regardless of perf. The problem in this specific case is that during the reload a security check calls IsDirectory on the file it is reloading, and IsDirectory errors out because it is using a cached FSRef for the file that went away. The cache didn't get cleared because the change was made externally - it wasn't made via the nsIFile object so the nsIFile object doesn't know about it.
I filed bug 455828 about removing the FSRef cache altogether, if we do that we don't need the patch here.
Bug 455828 landed on trunk, fixes this.
Status: NEW → RESOLVED
Last Resolved: 10 years ago
Resolution: --- → FIXED
Flags: wanted1.9.0.x+ → wanted1.9.0.x-
You need to log in before you can comment on or make changes to this bug.