312192 - Firefox loses track file:// page if that file's parent directory changes

Status: RESOLVED WORKSFORME

(Core :: XPCOM, defect)

Description

[Chris Dolan]

Firefox v1.5b2, MacOS X 1.4.2

If Firefox has a file:// url open and that file and its parent directory are
deleted and recreated, Firefox can no longer find the file.  For me, this
scenario arises because the Perl Devel::Cover debugging tool creates a directory
with summary HTML files every time it runs.  When it runs and rebuilds the
summary a reload in Firefox causes a false "File not found" error.

Steps to reproduce:
 1) Create a simple HTML file called foo.html
 2) In Terminal, type "open foo.html"
 3) In Terminal, "mkdir foo; cp foo.html foo"
 4) In Firefox, change location to add "foo/" subdir to the URL
    (in my case, file://localhost/Users/chris/foo.html
     becomes file://localhost/Users/chris/foo/foo.html)
 5) In Terminal, "/bin/rm -f foo; mkdir foo; cp foo.html foo"
 6) In Firefox, Cmd-R

Actual result:
 "File not found
  Firefox can't find the file at /Users/chris/foo/foo.html.
   * Check the file name for capitalization or other typing errors.
   * Check to see if the file was moved, renamed or deleted."

Expected result:
 Page reloads


I can only reproduce the bug with those exact steps.  The following changes to
the procedure no longer reproduce the bug:
 * Just changing foo/foo.html without deleting and remaking the dir
   (i.e. change step 5 to simply "/bin/cp foo.html foo")
 * Type Cmd-L Enter instead of Cmd-R
   (i.e. change step 6)
 * Typing "open foo/foo.html" instead of "open foo.html" and changing the URL
   (i.e. change step 2 and omit step 4)

Those three points lead me to believe the bug relates to caching a parent
directory inode for file:// urls.

This bug is not reproduceable in FF 1.0.7.  I have only tested it in 1.5b2 and
1.0.7.

(I doubt it matters, but I have Firefox set to open external URLs in a new tab
of the most recent window)

Comment 1

[benc]

If you load the URL again (by pressing return in the URL bar) instead of pressing the reload button, what happens?

Comment 2

[Chris Dolan]

(In reply to comment #1)
> If you load the URL again (by pressing return in the URL bar) instead of
> pressing the reload button, what happens?

That fixes it.  I documented that above (somewhat obscurely) as "Cmd-L Enter".

Comment 3

[Chris Dolan]

Note: there is a typo in the original steps to reproduce.  I meant to type "/bin/rm -rf foo" not "/bin/rm -f foo".

This bug still exists in 1.5.0.1 and Mac OS X 10.4.5.  I've reproduced this bug on both my home and work computers.

This bug certainly is obscure, but it concerns me because it suggests that the caching mechanism is behaving oddly for file:// urls, which might have more serious implications.

Comment 4

[Boris Zbarsky [:bzbarsky]]

This worksforme on Linux.  Are we actually caching something weird somewhere on mac?

Comment 5

[Mark Mentovai]

This is because we're caching FSRefs in nsLocalFileOSX.cpp.  FSRefs are like references to inodes and don't contain pathnames.

Comment 6

[Boris Zbarsky [:bzbarsky]]

So where should this bug live?  Assigned to Darin is probably wrong; widget:mac is wrong too.  Should we have components for platform-specific XPCOM stuff?

Comment 7

[Mark Mentovai]

This belongs to Josh or me (unless someone else wants to take it).  core.xpcom is the best of the currently available components.

Comment 8

[Håkan Waara]

This worksforme on Firefox trunk 2006-04-19, OS X 10.4.6

Chris, can you see if this bug still exists on a nightly build?

Comment 9

[Chris Dolan]

(In reply to comment #8)
> This worksforme on Firefox trunk 2006-04-19, OS X 10.4.6
> 
> Chris, can you see if this bug still exists on a nightly build?
> 

Yes, reproduced with "Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.9a1) Gecko/20060423 Minefield/3.0a1"
  --Chris

P.S. Wow, nightlies are much harder to find in the current website layout!  I hadn't downloaded one in quite a while...

Comment 10

[Håkan Waara]

Attachment: Patch, but still not working

Been debugging this for a while, but it's strange.

nsFileChannel::MakeFileInputStream() calls into IsDirectory() which for some reason thought it could use the cached fsref. This is wrong, AFAICS (IsFile(), IsSymLink() and the other Is*() methods don't assume this).   This is what the patch changes.

Now, what's weird is that even with this patch applied, when we try to get a  fresh fsref, using the correct and updated CFURLRef, ::CFURLGetFSRef() still returns false which usually means "no file found".  Thus we show that error.

Shouldn't ::CFURLGetFSRef() guarantee to give an updated FSRef given a correct/existing CFURL?

Comment 11

[Mark Mentovai]

(In reply to comment #10)
> nsFileChannel::MakeFileInputStream() calls into IsDirectory() which for some
> reason thought it could use the cached fsref. This is wrong, AFAICS (IsFile(),
> IsSymLink() and the other Is*() methods don't assume this).

IsFile uses the cached FSRef.  So does Equals (called with an nsIHashable argument).

> Now, what's weird is that even with this patch applied, when we try to get a 
> fresh fsref, using the correct and updated CFURLRef, ::CFURLGetFSRef() still
> returns false which usually means "no file found".  Thus we show that error.
> 
> Shouldn't ::CFURLGetFSRef() guarantee to give an updated FSRef given a
> correct/existing CFURL?

Yes.  Where are you seeing this?  GetFSRefInternal?  Can you use CFURLGetString on whichURLRef to verify that the CFURLRef really points where you think it does?

Do you still see this if you bypass the cache at the source by implementing GetFSRefInternal thusly?:

nsresult nsLocalFile::GetFSRefInternal(FSRef& aFSRef, PRBool bForceUpdateCache)
{
  // bForceUpdateCache is unused
  CFURLRef whichURLRef = mFollowLinks ? mTargetRef : mBaseRef;
  if (::CFURLGetFSRef(whichURLRef, &aFSRef))
    return NS_OK;
  return NS_ERROR_FILE_NOT_FOUND;
}

Also, note this in the CFURLGetFSRef docs:

The function cannot create an FSRef object if the path specified by url contains an alias. The function can, however, traverse symbolic links.

(My note: the path can't contain an alias, but it's OK if the leaf is an alias.)

Comment 12

[Benjamin Smedberg]

Mac is using the localfileunix implementation now, I believe this is fixed.