[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#15727: Bug: cp <-a|-archive> (w/<-f|--remove-destination>) breaks if
From: |
Bernhard Voelker |
Subject: |
bug#15727: Bug: cp <-a|-archive> (w/<-f|--remove-destination>) breaks if one of files is a dir and other not |
Date: |
Mon, 28 Oct 2013 21:56:14 +0100 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130329 Thunderbird/17.0.5 |
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