333524 - nsDirectoryEnumerator behaves differently on Windows

Status: RESOLVED WONTFIX

(Core Graveyard :: File Handling, defect)

Description

[Shane Caraveo]

User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.0.1) Gecko/20060111 Firefox/1.5.0.1
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.0.1) Gecko/20060111 Firefox/1.5.0.1

While looking at some xpcom registration issues in pyxpcom, I discovered that Windows behaves different in nsDirectoryEnumerator than linux or osx.  The difference is that, in HasMoreElements, windows will check if the file exists, and if not, it will recursively call HasMoreElements.  

I would assume that this will only happen if files (later in the array than the current position) are removed while iterating through the list.

Reproducible: Always

Comment 1

[Shane Caraveo]

hopefully a bit better explanation in the python code below.

Given that a file is removed during iteration, and it is a file that has not been retrieved yet via GetNext...

# windows will not fail, it skips non-existent files
# osx fails in HasMoreElements, so you don't process the entire directory
while dirEntries.HasMoreElements(): 
    #linux returns a non-existent file or fails here
    entry = dirEntries.GetNext(components.interfaces.nsIFile) 


Look in xpcom/io/nsLocalFileWin.cpp, nsDirEnumerator::HasMoreElements.  (Currently at line 704) you will see where the existence of the file is tested.

In xpcom/io/nsLocalFileOSX.cpp and xpcom/io/nsLocalFileUnix.cpp there is no similar check.

So, if a file has been removed during iteration, windows will continue to the next file, while OSX will return an error.  

I beleive Linux will also continue, but give back a non-existent file (or error out, not sure what readdir will return) in GetNext.

Comment 2

[Todd Whiteman]

Expired.