-
Notifications
You must be signed in to change notification settings - Fork 4.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix artifact/symlink mismatch detection #15700
Conversation
73ff93a
to
8f5d597
Compare
bf0e72e
to
fcef379
Compare
@coeuvre Friendly ping |
src/main/java/com/google/devtools/build/lib/skyframe/SkyframeActionExecutor.java
Outdated
Show resolved
Hide resolved
src/main/java/com/google/devtools/build/lib/skyframe/ActionMetadataHandler.java
Show resolved
Hide resolved
fcef379
to
31618be
Compare
13caa68
to
9700359
Compare
The check in ActionMetadataHandler that an output declared to be a symlink is indeed created as a symlink by the action was ineffective as it would only run if a stat of the output showed that is already was a symlink. The test only passed by accident since it runs sandboxed and the sandbox setup would call Path.readSymbolicLink on what it expects to be a symlink. As this does not happen on Windows, the test correctly fails there. This is fixed by calling Path.readSymbolicLink on the output path of an expected symlink before rather than after stat-ing it and trusting the file type contained in the stat info. With this issue fixed, bazel_symlink_test can be enabled on Windows with the following test-only changes: * Pass --windows_enable_symlinks as a startup option. * Use relative instead of absolute symlink targets as these have consistent shape under Unix and Windows. * Use python to create symlinks rather than `ln -s`, which doesn't seem to be able to create unresolved symlinks on Windows.
9700359
to
0e43c7c
Compare
d6e4aaf
to
bf04a68
Compare
bf04a68
to
8cbf26a
Compare
# We use python rather than a simple ln since the latter doesn't handle dangling symlinks on | ||
# Windows. | ||
mkdir -p symlink_helper | ||
cat > symlink_helper/BUILD <<EOF |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit: 'EOF' is generally preferred unless you need variable substitution. If you are OK with this, I am happy to change that as part of the import process.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could you take care of it? I'm on mobile atm. Thanks!
Another minor edit could be useful in the commit message:
I think we established that trusting stat output is actually OK, it's just that we didn't look whether it matches the expectation, not that it cannot be used. |
@@ -370,25 +357,35 @@ def _a_impl(ctx): | |||
) | |||
return DefaultInfo(files = depset([output])) | |||
|
|||
a = rule(implementation = _a_impl, attrs = {"link_target": attr.string()}) | |||
a = rule( | |||
implementation = _a_impl, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
FYI: I will remove the trailing space from this line as part of importing this change. You can delete that yourself if you prefer.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks!
I updated the PR description and am fine with you taking care of the nits. Thanks for the review! |
more nitting in the new sentence I would replace "trusting" with something like "assuming the type matches the artifact type (file vs symlink)." |
Changed. Not sure I wrapped the lines correctly though, so maybe reflow the text during the import. |
Thank you! FYI, I am in the process of merging that internally now. All tests passed, so looking good. Will update the PR once it is merged. Thank you so much for creating this change (and enduring my nitpicking)! It was a pleasure to work with you on that! |
The change was merged in 666fce5. Thank you for the contribution! |
The check in ActionMetadataHandler that an output declared to be a
symlink is indeed created as a symlink by the action was ineffective as
it would only run if a stat of the output showed that is already was a
symlink. The test only passed by accident since it runs sandboxed and
the sandbox setup would call Path.readSymbolicLink on what it expects to
be a symlink. As this does not happen on Windows, the test correctly
fails there.
This is fixed by calling Path.readSymbolicLink on the output path of
an expected symlink and handling errors appropriately rather
than
assuming the type returned by stat matches the artifact type (file vs symlink).
With this issue fixed, bazel_symlink_test can be enabled on Windows with
the following test-only changes:
consistent shape under Unix and Windows.
ln -s
, which doesn't seemto be able to create unresolved symlinks on Windows.
Work towards #10298