`FileManager.enumerator(at:)` stops iterating upon seeing path that exceeds `MAX_PATH` on Windows

[ahoppen]

Run the following to create a file at a path that exceeds MAXPATH

cd $HOME\Desktop
mkdir directoryTest
cd directoryTest
echo a > a.txt
echo a > z.txt
mkdir eeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee
subst Z: .\eeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee\
Z:
echo a > eeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee.txt

Now run

import Foundation

let enumerator = FileManager.default.enumerator(at: URL(fileURLWithPath: #"C:\Users\alex\Desktop\directoryTest"#), includingPropertiesForKeys: nil)
while let url = enumerator?.nextObject() as? URL {
  print(url)
}

Notice how it outputs

file:///C:/Users/alex/Desktop/directoryTest/z.txt
file:///C:/Users/alex/Desktop/directoryTest/eeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee/

Directory iteration stops upon reaching the eeeee…txt file that exceeds MAX_PATH and a.txt is never printed. I would expect directory iteration to either

• Skip the files that exceed the maximum path length but continue iteration afterwards or
• Return all files even those that exceed the maximum path length

but not to stop iteration upon reaching the first file that exceeds the maximum path length altogether.

[jmschonfeld]

@ahoppen the reason that enumeration stops here is because an error has occurred. In particular, the error is:

Error Domain=NSCocoaErrorDomain Code=260 "The file doesn’t exist." on file:///C:/Users/jmschonfeld/Desktop/testDir/eeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee/eeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee.txt

I suspect some API which we are calling is not handling the long paths well. The documentation states that, for the error handler parameter:

If you specify nil for this parameter, the enumerator object continues to enumerate items as if you had specified a block that returned true.

However it seems like on Windows that behavior is the opposite:

swift-corelibs-foundation/Sources/Foundation/FileManager+Win32.swift

Lines 326 to 329 in 21b3196

	guard let handler = _errorHandler else { return nil }
	if !handler(url, _NSErrorWithWindowsError(GetLastError(), reading: true, paths: [url.path])) {
	return nil
	}

So I agree it seems like there's two problems here:

1. The default (nil) error handler is the opposite of what is documented (we should confirm what is documented matches Darwin behavior)
2. We error out while handling paths that are beyond the max path length. I'm not sure if that can be fixed, we'll have to see if Windows has APIs we can use to work around this, but it's worth investigating.

For now if you need to work around issue number 1, you can provide a custom error handler which returns true

[ahoppen]

Oh, great. Thanks for the detailed analysis. We’re not seeing any long path related issues right now because I shortened all paths sufficiently but I’ll use that workaround when we see an issue next time.

[jmschonfeld]

The first part of the issue (the default error handler behavior on Windows) will be resolved by #5136

[ahoppen]

Thanks for the fix @jmschonfeld. That was the issue that bogged me more than skipping directories that exceed MAX_PATH (which is somewhat understandable, I think).