[8.6.0] Compensate for Windows filesystems lacking junction support

[rdesgroppes]

Problem:
Bazel fails completely on Windows when using filesystems that don't support junction/reparse point operations (e.g., virtiofs, VirtualBox shared folders, network drives, RAM disks).

The fatal error occurs when ReadSymlinkOrJunction fails during path resolution (e.g., when Starlark code calls .realpath): "Cannot read link: DeviceIoControl: Incorrect function". This causes build analysis to abort completely.

Additionally, CreateJunction failures when creating convenience symlinks produce cryptic error messages, though these were already non-fatal warnings.

Both fail because DeviceIoControl returns ERROR_INVALID_FUNCTION when the filesystem doesn't implement FSCTL_GET_REPARSE_POINT or FSCTL_SET_REPARSE_POINT operations.

Proposed solution:
Handle ERROR_INVALID_FUNCTION gracefully by treating it as a "not supported" condition rather than a fatal error:

1. in ReadSymlinkOrJunction (file.cc:592): return kNotALink instead of kError when ERROR_INVALID_FUNCTION occurs. This allows path resolution to continue for non-symlink paths on unsupported filesystems.
2. in CreateJunction (file.cc:461): return new kNotSupported result code when ERROR_INVALID_FUNCTION occurs. This produces clear "filesystem does not support junctions" warnings instead of cryptic "Incorrect function" messages. This improves UX but doesn't change behavior (these failures were already non-fatal).

This follows the try-first, fallback-on-error pattern (EAFP) used by other major projects when handling unsupported filesystem operations.

Prior art:

• Rust (Win: Fix std::fs::rename failing on Windows Server by attempting the non-atomic rename first rust-lang/rust#138133): checks ERROR_INVALID_FUNCTION, ERROR_NOT_SUPPORTED, and ERROR_INVALID_PARAMETER for filesystem operation fallbacks in std::fs::rename.
• Microsoft STL (<filesystem>: read_symlink does not work with junctions microsoft/STL#2077): handles junctions and reparse point errors including ERROR_INVALID_PARAMETER with robust fallback logic in filesystem.cpp.
• Go (path/filepath: use Windows GetFinalPathNameByHandle instead of os.Readlink to implement EvalSymlinks golang/go#20506): uses fallback strategies when symlink APIs are unavailable on different Windows versions.
• WinFsp (Creation of a disk file system may fail winfsp/winfsp#88): documents that ERROR_INVALID_FUNCTION indicates STATUS_NOT_IMPLEMENTED for unsupported operations.
• Microsoft Learn: recommends checking FILE_SUPPORTS_REPARSE_POINTS flag via GetVolumeInformation, but try-catch approach is simpler and handles edge cases where detection succeeds but operations fail.

Impact:

• enables Bazel to work on virtiofs, VirtualBox shared folders, RAM disks, and other filesystems that don't support Windows junction operations.
• convenience symlinks (bazel-bin, bazel-out, etc.) still won't be created, but now with clearer error messages.

Limitations:
Full junction support would require filesystem-level changes (e.g., virtiofs driver improvements).

Testing:
Tested on Windows 11 VM with host directory mounted via virtiofs, with rules_pkg. Before change: build analysis aborted with "Cannot read link" fatal error. After change: builds complete successfully with clearer warnings about unsupported junctions for convenience symlinks.

Closes #27598.

PiperOrigin-RevId: 833360316
Change-Id: I3751602b2bd793c1cee75b7b66fa73c955a72517
(cherry-picked from commit dab96fc)

[gemini-code-assist]

Code Review

This pull request effectively addresses the issue of Bazel failing on Windows filesystems that lack junction/reparse point support. By gracefully handling ERROR_INVALID_FUNCTION in both CreateJunction and ReadSymlinkOrJunction, the changes prevent fatal errors and provide clearer warnings. The introduction of kNotSupported in CreateJunctionResult and treating the error as kNotALink in ReadSymlinkOrJunction aligns with the described try-first, fallback-on-error pattern, enhancing the robustness and compatibility of Bazel on diverse Windows environments.

[iancha1992]

Dupe of #28367