Skip to content
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

atomicallyWriteTo: remove temporary file prior to creating it #19243

Conversation

EdSchouten
Copy link
Contributor

This change is the same in spirit to #19241. When using Bazel in combination with bb_clientd, bb_clientd may restore a copy of bazel-out/ from a snapshot. Files restored from the snapshot are not mutable, as they may be backed by other snapshots, a remote CAS, etc. etc. etc..

This change extends atomicallyWriteTo() to always write contents into a new file that is guaranteed to be writable. The logic that's added here is merely copy-pasted from what's already present at the bottom of the same function.

@github-actions github-actions bot added awaiting-review PR is awaiting review from an assigned reviewer team-Performance Issues for Performance teams labels Aug 14, 2023
@@ -67,6 +67,11 @@ public byte[] atomicallyWriteRelativeTo(Path execRoot, String uniqueSuffix) thro
protected byte[] atomicallyWriteTo(Path outputPath, String uniqueSuffix) throws IOException {
Path tmpPath = outputPath.getFileSystem().getPath(outputPath.getPathString() + uniqueSuffix);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The fact that you're seeing this problem (and we've seen some similar ones) just goes to show that the uniqueSuffix is insufficiently unique. We should rather add something truly unique here and have the uniqueSuffix just serve to indicate what it's used for (which is most of the usage I see today).

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actually using a deterministic suffix here is actually not that bad. It means that if the process is repeated, any stale temporary files get cleaned up automatically, right?

This change is the same in spirit to bazelbuild#19241. When using Bazel in
combination with bb_clientd, bb_clientd may restore a copy of bazel-out/
from a snapshot. Files restored from the snapshot are not mutable, as
they may be backed by other snapshots, a remote CAS, etc. etc. etc..

This change extends atomicallyWriteTo() to always write contents into a
new file that is guaranteed to be writable. The logic that's added here
is merely copy-pasted from what's already present at the bottom of the
same function.
@EdSchouten EdSchouten force-pushed the eschouten/20230814-sandbox-tempfile-2 branch from d412613 to ef88553 Compare August 31, 2023 07:32
@EdSchouten
Copy link
Contributor Author

EdSchouten commented Sep 18, 2023

@coeuvre @larsrc-google PTAL!

@coeuvre coeuvre added awaiting-PR-merge PR has been approved by a reviewer and is ready to be merge internally and removed awaiting-review PR is awaiting review from an assigned reviewer labels Oct 5, 2023
@copybara-service copybara-service bot closed this in 423a368 Oct 6, 2023
@github-actions github-actions bot removed the awaiting-PR-merge PR has been approved by a reviewer and is ready to be merge internally label Oct 6, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
team-Performance Issues for Performance teams
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants