Repository navigation
cp: create removed destinations exclusively - #15330
abendrothj wants to merge 1 commit into
Conversation
Merging this PR will improve performance by 13.13%1 warning, 1 note
Performance Changes
Tip Curious why performance improved? Comment Comparing Footnotes
|
8270ad8 to
be468b3
Compare
On macOS, a streamed destination is now created at 0600, as on Linux, instead of 0622 minus the umask.
be468b3 to
9d7881e
Compare
There was a problem hiding this comment.
Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.
An organization owner can choose the repository organization as the billing source for reviews requested by members with a paid Copilot license. Learn about Copilot code review billing. Review the Copilot code review billing settings.
Closes #15329
When the destination was missing, or cp had removed or renamed it (
--remove-destination,-f,--backup), cp created the new file withoutO_EXCL. Whatever appeared at that name in between was opened, and a symlink was followed.cp now creates the file exclusively in those cases and fails if anything is there, with GNU's messages. A destination that is overwritten in place is opened as before. The flag lives in uucore's
create_dest_restrictive, whereexclusivereplacesnofollow. Its onlynofollowcaller, mv's cross-device fallback, now creates exclusively too, as GNU mv does. mv can't be paused between its removal and the create, so that path has no test of its own; the uucore unit tests cover the exclusive create.--attributes-onlycreates exclusively on Windows too; the Windows data copy still usesfs::copy.util/check-safe-traversal.shacceptsO_EXCLas well asO_NOFOLLOWfor mv's create.Checked against GNU coreutils 9.12 for
--remove-destinationwith a symlink, a dangling symlink and a regular file created after the removal: messages and exit status match. Addedtest_cp_does_not_open_dest_recreated_after_removal, which fails without the change on macOS and Linux.