Repository navigation
filesystem.py: improve write_tmp_and_move and use throughout - #52653
Merged
Merged
Conversation
The `mkstemp` + `rename` pattern is used in various in Spack, which is a reasonable way to get a new file in a given directory to atomically replace a target file. The downside is that it doesn't respect umask, cause it's supposed to "safe" with mode 0600. Instead, improve `write_tmp_and_move` to create a randomized temporary file name opened with "x" (O_CREAT | O_EXCL), which both keeps the atomicity guarantees and creates new files with 0666 & ~umask like a plain open(..., "w"). Permissions of an existing destination file are preserved, and the temporary file is removed on failure. Users can still do an `fchmod` with the yielded file. Signed-off-by: Harmen Stoppels <[email protected]>
haampie
changed the title
write_tmp_and_move and use throughout
2 of 11 tasks
alalazo
approved these changes
Jul 6, 2026
haampie
added a commit
that referenced
this pull request
Jul 6, 2026
The `mkstemp` + `rename` pattern is used in various places in Spack, which is a reasonable way to get a new file in a given directory to atomically replace a target file. The downside is that it doesn't respect umask, cause it's supposed to be "safe" too (mode 0600). That was realized in #52369 but not in #52041. Instead, improve `write_tmp_and_move` to create a randomized temporary file name opened with "x", which both keeps the atomicity guarantees and respects umask. Permissions of an existing destination file are preserved, and the temporary file is removed on failure. Call sites can still do an `fchmod` on the yielded file. (Not part of `spack.package` fortunately) Signed-off-by: Harmen Stoppels <[email protected]>
haampie
added a commit
that referenced
this pull request
Jul 6, 2026
The `mkstemp` + `rename` pattern is used in various places in Spack, which is a reasonable way to get a new file in a given directory to atomically replace a target file. The downside is that it doesn't respect umask, cause it's supposed to be "safe" too (mode 0600). That was realized in #52369 but not in #52041. Instead, improve `write_tmp_and_move` to create a randomized temporary file name opened with "x", which both keeps the atomicity guarantees and respects umask. Permissions of an existing destination file are preserved, and the temporary file is removed on failure. Call sites can still do an `fchmod` on the yielded file. (Not part of `spack.package` fortunately) Signed-off-by: Harmen Stoppels <[email protected]>
becker33
pushed a commit
that referenced
this pull request
Jul 6, 2026
The `mkstemp` + `rename` pattern is used in various places in Spack, which is a reasonable way to get a new file in a given directory to atomically replace a target file. The downside is that it doesn't respect umask, cause it's supposed to be "safe" too (mode 0600). That was realized in #52369 but not in #52041. Instead, improve `write_tmp_and_move` to create a randomized temporary file name opened with "x", which both keeps the atomicity guarantees and respects umask. Permissions of an existing destination file are preserved, and the temporary file is removed on failure. Call sites can still do an `fchmod` on the yielded file. (Not part of `spack.package` fortunately) Signed-off-by: Harmen Stoppels <[email protected]>
Aiden2244
pushed a commit
to Aiden2244/spack
that referenced
this pull request
Jul 20, 2026
…#52653) The `mkstemp` + `rename` pattern is used in various places in Spack, which is a reasonable way to get a new file in a given directory to atomically replace a target file. The downside is that it doesn't respect umask, cause it's supposed to be "safe" too (mode 0600). That was realized in spack#52369 but not in spack#52041. Instead, improve `write_tmp_and_move` to create a randomized temporary file name opened with "x", which both keeps the atomicity guarantees and respects umask. Permissions of an existing destination file are preserved, and the temporary file is removed on failure. Call sites can still do an `fchmod` on the yielded file. (Not part of `spack.package` fortunately) Signed-off-by: Harmen Stoppels <[email protected]>
2 tasks done
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Closes #52651
The
mkstemp+renamepattern is used in various places in Spack, which isa reasonable way to get a new file in a given directory to atomically
replace a target file. The downside is that it doesn't respect umask, cause
it's supposed to be "safe" too (mode 0600).
That was realized in #52369 but not in #52041.
Instead, improve
write_tmp_and_moveto create a randomized temporaryfile name opened with "x", which both keeps the atomicity guarantees and
respects umask. Permissions of an existing destination file are preserved, and
the temporary file is removed on failure.
Call sites can still do an
fchmodon the yielded file.(Not part of
spack.packagefortunately)