The default bug view has changed. See this FAQ.

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

VERIFIED FIXED in mozilla9

Status

()

Core
XPCOM
P4
minor
VERIFIED FIXED
9 years ago
5 years ago

People

(Reporter: Zbynek Winkler, Assigned: bbondy)

Tracking

unspecified
mozilla9
x86
Windows XP
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [bugday-20110401])

Attachments

(2 attachments, 1 obsolete attachment)

(Reporter)

Description

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

Comment 1

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

Comment 2

6 years ago
Confirming the same on Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b11) Gecko/20100101 Firefox/4.0b11.
Created attachment 522118 [details]
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)

Updated

6 years ago
Assignee: nobody → netzen
(Assignee)

Comment 4

6 years ago
Created attachment 556213 [details] [diff] [review]
Patch for better error handling and exists fix

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)
(Assignee)

Comment 5

6 years ago
Created attachment 556257 [details] [diff] [review]
Patch for better error handling and exists fix v2

Fixed Minor problem from last patch
Attachment #556213 - Attachment is obsolete: true
Attachment #556257 - Flags: review?(benjamin)
Attachment #556213 - Flags: review?(benjamin)
(Assignee)

Updated

6 years ago
Blocks: 300692
(Assignee)

Updated

6 years ago
Blocks: 682571
Attachment #556257 - Flags: review?(benjamin) → review+
(Assignee)

Comment 6

6 years ago
Pushed to try:
https://tbpl.mozilla.org/?tree=Try&usebuildbot=1&rev=7372a2522155
(Assignee)

Comment 7

6 years ago
Pushed to inbound:
http://hg.mozilla.org/integration/mozilla-inbound/rev/519c7eed899a
https://hg.mozilla.org/mozilla-central/rev/519c7eed899a
Status: NEW → RESOLVED
Last Resolved: 6 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.
(Assignee)

Comment 10

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

Comment 12

6 years ago
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.
(Assignee)

Comment 13

6 years ago
> 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!

Comment 14

6 years ago
(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.