322686 - replacing a local file, then reloading, sometimes claims "file not found"

Status: RESOLVED FIXED

(Core :: Networking: File, defect, P1)

Description

[Phil Schwan]

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"

Comment 1

[Mike Shaver (:shaver -- probably not reading bugmail closely)]

> 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.

Comment 4

[/\/\arcio Galli]

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

Comment 5

[/\/\arcio Galli]

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. 

Comment 6

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

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.

Comment 7

[Mike Shaver (:shaver -- probably not reading bugmail closely)]

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.

Comment 10

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

No longer minor I don't think -- it crops up way too often.

Comment 11

[Josh Aas]

Attachment: 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.

Comment 12

[Josh Aas]

I filed bug 455828 about removing the FSRef cache altogether, if we do that we don't need the patch here.

Comment 13

[Josh Aas]

Bug 455828 landed on trunk, fixes this.