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

RESOLVED FIXED

Status

()

Core
Networking: File
P1
major
RESOLVED FIXED
12 years ago
9 years ago

People

(Reporter: Phil Schwan, Assigned: Josh Aas)

Tracking

({fixed1.9.1})

Trunk
PowerPC
Mac OS X
fixed1.9.1
Points:
---
Bug Flags:
wanted-next +
blocking1.9.1 +
wanted1.9.0.x -

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(1 obsolete attachment)

(Reporter)

Description

12 years ago
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.

Updated

12 years ago
Assignee: darin → nobody
QA Contact: benc → networking.file

Updated

10 years ago
Duplicate of this bug: 398648

Updated

10 years ago
Duplicate of this bug: 311382

Comment 4

10 years ago
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

Comment 5

10 years ago
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.
Flags: wanted1.9.0.x+
Flags: blocking1.9?
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.

Updated

10 years ago
Flags: tracking1.9? → blocking1.9?
Flags: blocking1.9? → wanted-next+

Updated

10 years ago
Duplicate of this bug: 444133
No longer minor I don't think -- it crops up way too often.
Severity: minor → major
Flags: blocking1.9.1?
(Assignee)

Updated

10 years ago
Flags: blocking1.9.1? → blocking1.9.1+
(Assignee)

Updated

10 years ago
Assignee: nobody → joshmoz
(Assignee)

Comment 11

10 years ago
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.
Attachment #339157 - Flags: review?(mstange)
(Assignee)

Updated

10 years ago
Priority: -- → P1
(Assignee)

Comment 12

10 years ago
I filed bug 455828 about removing the FSRef cache altogether, if we do that we don't need the patch here.
(Assignee)

Updated

10 years ago
Depends on: 455828
(Assignee)

Updated

10 years ago
Attachment #339157 - Attachment is obsolete: true
Attachment #339157 - Flags: review?(mstange)
(Assignee)

Comment 13

10 years ago
Bug 455828 landed on trunk, fixes this.
Status: NEW → RESOLVED
Last Resolved: 10 years ago
Resolution: --- → FIXED
Keywords: fixed1.9.1
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.