-
-
Notifications
You must be signed in to change notification settings - Fork 1.6k
cp: force mode: try to open destination for write to check if delete is required #8496
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
base: main
Are you sure you want to change the base?
Conversation
b331360
to
fe1dd15
Compare
GNU testsuite comparison:
|
ok, this does not work (related GNU test fails). I'll further investigate. |
14837cc
to
9e89ef5
Compare
GNU testsuite comparison:
|
is_symlink_loop(dest) || fs::metadata(dest)?.permissions().readonly() | ||
is_symlink_loop(dest) | ||
|| fs::metadata(dest)?.permissions().readonly() | ||
|| (dest.is_file() && OpenOptions::new().write(true).open(dest).is_err()) |
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.
The condition dest.is_file() check seems redundant since
OpenOptions::new().write(true).open(dest) will fail on non-files anyway, and this creates an unnecessary extra syscall
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.
I tried that first, but the open(dest) gets stuck when the destination is a FIFO. It does not return.
So far cp only checked if the metadata of the destination file indicates read-only permissions. In order to handle the case where the destination file is in use, we try to open the destination file for writing. Also other cases which prevent overwriting can be detected that way. For the test case we copy the coreutils binary to a test directory. Then use the copy to try to copy a file over itself. This should fail in non-force mode, but succeed in force mode.
9e89ef5
to
f02093e
Compare
@sylvestre thank you for your review. I addressed the findings. Please check. |
fails here:
|
GNU testsuite comparison:
|
ok, this needs more investigations. I'll change the PR back to draft. |
So far cp only checked if the metadata of the destination file indicates
read-only permissions. In order to handle the case where the destination
file is in use, we try to open the destination file for writing. Also
other cases which prevent overwriting can be detected that way.
For the test case we copy the coreutils binary to a test directory. Then
use the copy to try to copy a file over itself. This should fail in
non-force mode, but succeed in force mode.
this fixes #8261