Subject: bug#15727: Bug: cp <-a|-archive> (w/<-f|--remove-destination>) breaks if one of files is a dir and other not

From: Bernhard Voelker <[email-masked]>
Date: Mon, 28 Oct 2013 21:56:14 +0100

Hi Linda,

On 10/28/2013 08:09 AM, Linda Walsh wrote:
> On 10/27/2013 5:38 PM, Pádraig Brady wrote:
>> So overwriting files with dirs and vice versa
>> is prohibited by POSIX.  The existing cp options
>> do not adjust this aspect. If you don't care what's
>> in the destination at all, why not just rm it before the copy?
> 
> 
> Um --- isn't that what the "--remove-destination" option is supposed to
> do?

"info coreutils 'cp invocation'" says:

  `--remove-destination'
       Remove each existing destination file before attempting to open it
       (contrast with `-f' above).

In this case, "file" really means a regular file (or socket, fifo, ...)
but no directory.  The documentation could be clearer about that ...

> Also note, I tried to use it with the "update" option, [...]

... and it may be a question to discuss whether --remove-destination
should be able to rmdir() emtpy directories, but that GNU extension
should never help you out in the case of non-empty directories.
I got the overall impression that you try to sync a source to a
destination.  Tools like rsync may be better for such a scenario
than cp(1) which is made primarily to

  cp: copy files and directories

Have a nice day,
Berny