Closed Bug 429484 Opened 12 years ago Closed 8 years ago

Win32 nsILocalFile.exists() returns false for an existing system file (such as hiberfile.sys or pagefile.sys)

Categories

(Core :: XPCOM, defect, P4, minor)

x86
Windows XP
defect

Tracking

()

VERIFIED FIXED
mozilla9

People

(Reporter: zbynek.winkler, Assigned: bbondy)

References

Details

(Whiteboard: [bugday-20110401])

Attachments

(2 files, 1 obsolete file)

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.13) Gecko/20080311 Firefox/2.0.0.13
Build Identifier: 2.0.0.13 and 3.0b5

var file = Components.classes['@mozilla.org/file/local;1'].createInstance(Components.interfaces.nsILocalFile);
file.initWithPath("c:\\hiberfil.sys"); 
alert(file.exists());

The code above shows false even though "dir /a c:\hiberfil.sys" shows it exists.
c:\>dir /a c:\hiberfil.sys
 Volume in drive C has no label.
 Volume Serial Number is 3C7A-79DB

 Directory of c:\

14.04.2008  08:33     1 072 091 136 hiberfil.sys
               1 File(s)  1 072 091 136 bytes
               0 Dir(s)   4 735 647 744 bytes free

Also iterating over nsILocalFile.directoryEntries does not show the files either.

Reproducible: Always
I see this on Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1pre) Gecko/20090611 Shiretoko/3.5pre, no duplicates, confirming.
Status: UNCONFIRMED → NEW
Component: Networking: File → XPCOM
Ever confirmed: true
QA Contact: networking.file → xpcom
Severity: normal → minor
Priority: -- → P4
Confirming the same on Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b11) Gecko/20100101 Firefox/4.0b11.
Attached file testcase
If I read the comment 0 correctly, hiberfil.sys and pagefile.sys files are NOT included in directoryEntries of "c:". I don't have XP, so I can't test.

In my win7 + ff36 (Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.16) Gecko/20110319 Firefox/3.6.16) hiberfil.sys and pagefile.sys are NOT included in directoryEntries of "c:". The attached test case opens 2 alerts for me with exists() being false.

In my win7 + ff4 (Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0) Gecko/20100101 Firefox/4.0) hiberfil.sys and pagefile.sys ARE included in directoryEntries of "c:". The attached test case opens 4 alerts for me with exists() being false.

The mentioned files actually exists on my disk.

It doesn't make much sense that directoryEntries return files that don't "exist".

An user (win xp sp3 + ff4) of my extension encountered this [1]. In my code I loop directoryEntries and do isDirectory() on the entry, which of course fails because the mentioned files don't "exist".

[1] http://code.google.com/p/savefileto/issues/detail?id=5
Whiteboard: [bugday-20110401]
Assignee: nobody → netzen
If a file exists, and is also either i) exclusively opened, or ii) locked, then we should be returning true from exists. 

If this patch gets r+ I will check the rest of the code base to see if I can spot any problems from changing this behaviour to the proper handling.  And I'll submit a second patch if necessary for any changes.
Attachment #556213 - Flags: review?(benjamin)
Fixed Minor problem from last patch
Attachment #556213 - Attachment is obsolete: true
Attachment #556257 - Flags: review?(benjamin)
Attachment #556213 - Flags: review?(benjamin)
Blocks: 300692
Blocks: 682571
Attachment #556257 - Flags: review?(benjamin) → review+
https://hg.mozilla.org/mozilla-central/rev/519c7eed899a
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla9
Should this be set to status-firefox9:fixed? 

Also, how do I utilize the attached testcase? It's not completely clear to me how to use it to verify the fix.
> Should this be set to status-firefox9:fixed? 

I'm not sure but it affects Core (all products) so I think it is correctly marked.

> how do I utilize the attached testcase

The easiest way is probably to use the Developer Assistant add-on:
https://addons.mozilla.org/en-US/firefox/addon/extension-developer/

Once installed right click somewhere near your URL bar and customize, and add the "Javascript Environment" button.  

Once added click it to open and paste the code from the test case. 

Please let me know if you want me to document the code more in the test case to explain it.
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:9.0a1) Gecko/20110922 Firefox/9.0a1

Tested using the following steps:
1) Install https://addons.mozilla.org/en-US/firefox/addon/extension-developer/
2) Add "Javascript Environment" button to the main toolbar
3) Create a temp file called hiberfil.sys in C:\ (was necessary due to lack of file)
4) Copy the following code:

var file = Components.classes['@mozilla.org/file/local;1'].createInstance(Components.interfaces.nsILocalFile);
file.initWithPath("c:\\hiberfil.sys"); 
alert(file.exists());

5) Click the "Javascript ENV" button on the toolbar
6) Paste the copied code
7) Click the Execute button

Result:
Alert dialog displaying true.
Repeating after removing the file displays false.

Setting to VERIFIED FIXED.
Status: RESOLVED → VERIFIED
This was not much of a test; the followed steps would work even before this fix was applied. 

This patch solves an issue which is encountered *exclusively* with system-locked files (such as the *real* hiberfil.sys), not with any other arbitrary (user-created) files.

(In reply to Anthony Hughes, Mozilla QA (irc: ashughes) from comment #11)
> Mozilla/5.0 (Windows NT 6.1; WOW64; rv:9.0a1) Gecko/20110922 Firefox/9.0a1
> 
> Tested using the following steps:
> 1) Install
> https://addons.mozilla.org/en-US/firefox/addon/extension-developer/
> 2) Add "Javascript Environment" button to the main toolbar
> 3) Create a temp file called hiberfil.sys in C:\ (was necessary due to lack
> of file)
> 4) Copy the following code:
> 
> var file =
> Components.classes['@mozilla.org/file/local;1'].createInstance(Components.
> interfaces.nsILocalFile);
> file.initWithPath("c:\\hiberfil.sys"); 
> alert(file.exists());
> 
> 5) Click the "Javascript ENV" button on the toolbar
> 6) Paste the copied code
> 7) Click the Execute button
> 
> Result:
> Alert dialog displaying true.
> Repeating after removing the file displays false.
> 
> Setting to VERIFIED FIXED.
> the followed steps would work even before this fix was applied. 

It would return false before this patch.  After this patch it would return true.

Additional things that can be tried to verify no regressions were introduced (these were both tried already by me but you can verify as well):
- Try an exclusively opened file like: C:\Users\bbondy\NTUSER.dat should still return true.
- Try a file which is not open and make sure it still returns true as it did before.


ondra zara if you have extra ideas please let us know. Thanks!
(In reply to Brian R. Bondy [:bbondy] from comment #13)

> 
> ondra zara if you have extra ideas please let us know. Thanks!

I have no other ideas and I strongly believe that the patch is correct :)

> > the followed steps would work even before this fix was applied. 
> 
> It would return false before this patch.  After this patch it would return
> true.
> 

It just came to me that when the "c:\hiberfil.sys" file was *not* present in the system prior to verifying, it must have been created (by the verifier) as an ordinary file, thus not being one of those system-locked files - which are the main subject of this issue. But no big deal here...
I assume that this was fixed for ff9. At least, exists() seems to work in ff9 but other isXxx() methods seem to fail. I filed bug 701721.
You need to log in before you can comment on or make changes to this bug.