child_process: Fix regression on Windows for FAT filesystems #16492
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This fixes a regression caused by #13993
As an optimization, the first call to
NtQueryDirectoryFilewould only ask for a single result and assume that if the result returned did not match the app_name exactly, then the unappended app_name did not exist. However, this relied on the assumption that the unappended app_name would always be returned first, but that only seems to be the case on NTFS. On FAT filesystems, the order of returned files can be different, which meant that it could assume the unappended file doesn't exist when it actually does.This commit fixes that by fully iterating the wildcard matches via
NtQueryDirectoryFileand taking note of any unappended/PATHEXT-appended filenames it finds. In practice, this strategy does not introduce a speed regression compared to the previous (buggy) implementation.(same benchmark as #13993, but different
PATHenvironment variable)Partially addresses #16374 (it fixes
zig buildon FAT32 when nozig-cacheis present, buterror.Unexpected NTSTATUS=0xc0000035still happens duringzig buildoncezig-cacheis created)Before (where
E:\is a FAT32 filesystem):After this commit:
Note: there's a fairly comprehensive standalone test for Windows spawn behavior, so as long as the tests pass we can have some confidence that this won't regress the spawn behavior:
https://github.com/ziglang/zig/blob/master/test/standalone/windows_spawn/main.zig