deno

93d5bfa2 - fix(ext/fs): retry without FILE_FLAG_BACKUP_SEMANTICS on Windows when driver rejects it (#34686)

fix(ext/fs): retry without FILE_FLAG_BACKUP_SEMANTICS on Windows when driver rejects it (#34686) ## Summary Some Windows file system drivers — notably ImDisk-backed memory disks — reject `FILE_FLAG_BACKUP_SEMANTICS` for regular files and return `ERROR_INVALID_FUNCTION` (\`os error 1\`). Deno passes that flag so `CreateFile` can open directories with the same code path as files, which causes \`Deno.readTextFile\`, \`Deno.writeTextFile\`, \`Deno.stat\`, \`Deno.lstat\` (and anything that goes through them, such as \`std/fs/exists\`) to fail on those volumes: \`\`\`txt Error: Incorrect function. (os error 1): readfile 'y:\a.txt' Error: Incorrect function. (os error 1): writefile 'y:\test.txt' Error: Incorrect function. (os error 1): stat 'y:\a.txt' \`\`\` This PR transparently retries the open without the flag when we see `ERROR_INVALID_FUNCTION`. Directories will still fail to open on the problematic drivers (they need the backup-semantics flag), but on those drivers only regular-file operations actually need to succeed. Any other error from the original open still propagates unchanged. The fallback covers both code paths that explicitly set the flag on Windows: - `open_with_checked_path` (used by `read_file_*`, `write_file_*`, `open_*`, and the text-file variants that delegate to them). - `stat` / `lstat` (each open the path with `access_mode(0)` plus the flag to grab metadata via `GetFileInformationByHandle` / `NtQueryInformationFile`). ## Test plan - [x] `cargo +1.95.0 check -p deno_fs` (Linux host) - [x] `cargo +1.95.0 clippy -p deno_fs --no-deps` - [x] `cargo +1.95.0 fmt --check -p deno_fs` - [ ] CI Windows job exercises the standard read/write/stat code paths Hard to add an automated test for the ImDisk-only failure mode here since we'd need to provision a memory-disk volume on the Windows CI runner. Fixes #26257 Closes denoland/divybot#406 Co-authored-by: divybot <divybot@users.noreply.github.com> Co-authored-by: Divy Srivastava <me@littledivy.com>