12

in the cp manpage, it lists the -f/--force option as: if an existing destination file cannot be opened, remove it and try again

for the --remove-destination option it says: remove each existing destination file before attempting to open it (contrast with --force)

So, the former first checks if it can be opened, if not, it deletes in anyway, while the latter just bypasses that step. I combined each with the -i option, and in both cases, it indicates what the permissions of the files are if it's write-protected.

The latter would seem to be more efficient, especially if recursively copying/overwriting large directories, but why maintain both options? What's the advantage of checking something it's going to over-ride anyway?

2 Answers 2

11

There's a distinction between the two (emphasis mine):

if an existing destination file cannot be opened, remove it and try again
remove each existing destination file before attempting to open it

In the first case, if the file can be opened, cp will attempt to replace only the contents. cp is not going to remove the file unnecessarily. This will retain the permissions and ownerships of the original file unless you specify that they're to be copied too.

The second case is useful when the contents can't be read (such as dangling symlinks).

1
  • Sometimes I would prefer trying to edit a file with low permissions in an effort to avoid to recreate it, or doing something else that could pass ownership to me since I have higher privileges therefore locking others out. Since there are many systems/accounts involved, some in a domain, some not, various filesystems and network file systems that mask owners and all that, I thought it was like a useful glitch or something. It never occurred to me to think of it in the links mapped somewhere on a disk construct. This answers so much. Thank you! Commented Mar 6, 2023 at 22:58
9

and: in case the destination file has multiple links (hardlinks), --remove-destination will not destroy the content of the other links. Instead just the link of the destination is removed (now we know, why "remove" is called "unlink" in deeper system functions) and a new file with a new inode is created.

1
  • This looks like an addendum to the accepted answer and should probably included there. Commented Sep 17, 2020 at 7:40

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.