Windows Server Data Deduplication Incorrectly Interpreted as Symlinks
#19 437 ouverte le 7 sept. 2023
Métriques du dépôt
- Stars
- (25 384 stars)
- Métriques de merge PR
- (Merge moyen 22j 20h) (77 PRs mergées en 30 j)
Description
Description of the bug:
Problem
When running Bazel on a Windows server with Data Deduplication turned on (see https://learn.microsoft.com/en-us/windows-server/storage/data-deduplication/overview), https://github.com/bazelbuild/bazel/blob/478c7e06924a4f277d2252610b8f675fc6faa6f7/src/main/native/windows/file.cc#L95 will interpret deduplicated files as symlinks. When the file is then read, https://github.com/bazelbuild/bazel/blob/478c7e06924a4f277d2252610b8f675fc6faa6f7/src/main/native/windows/file.cc#L533 will return "Unknown link type".
IsSymlinkOrJunction only checks if the file is a reparse point, not that the reparse point is a symlink or junction. All reparse points listed here except for IO_REPARSE_TAG_SYMLINK and IO_REPARSE_TAG_MOUNT_POINT (which are handled explicitly in ReadSymlinkOrJunction) are handled incorrectly.
This issue was brought up in https://github.com/bazelbuild/bazel/issues/11237 but for IO_REPARSE_TAG_DFS reparse points. In it, there was a suggestion to change IsSymlinkOrJunction to look at the reparse tag in addition to the reparse point flag, but it was never committed. I believe this change would address the problem.
Context
My company wants to use Bazel to compile their product, however we are intermittently getting error like:
[0 / 5] [Prepa] BazelWorkspaceStatusAction stable-status.txt
ERROR: {obfuscated path}/BUILD:16:10: {obfuscated target}: error reading file '{obfuscated path}': Cannot read link (name={obfuscated path}): unknown link type
ERROR: {obfuscated path}/BUILD:16:10: 1 input file(s) are in error
Target {obfuscated target} failed to build
After investigating, all files that are reported as "unknown link type" have been deduplicated by Windows after the deduplication delay.
This is preventing us from adopting Bazel, as we can't have intermittent errors like this. We can't just turn off file deduplication because it saves us a very appreciable amount of disk space.
Which category does this issue belong to?
Core
What's the simplest, easiest way to reproduce this bug? Please provide a minimal example if possible.
On a Windows Server machine with deduplication turned on for a volume, build anything with Bazel after the files have been deduplicated (there is a configurable delay for deduplication).
Which operating system are you running Bazel on?
Windows Server
What is the output of bazel info release?
release 6.1.1
If bazel info release returns development version or (@non-git), tell us how you built Bazel.
No response
What's the output of git remote get-url origin; git rev-parse master; git rev-parse HEAD ?
fatal: not a git repository (or any of the parent directories): .git
fatal: not a git repository (or any of the parent directories): .git
fatal: not a git repository (or any of the parent directories): .git
Is this a regression? If yes, please try to identify the Bazel commit where the bug was introduced.
This does not appear to be a regression. It just never worked.
Have you found anything relevant by searching the web?
https://github.com/bazelbuild/bazel/issues/11237 https://github.com/bazelbuild/bazel/issues/7907
Any other information, logs, or outputs that you want to share?
No response