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

[Linda Walsh]

On 10/28/2013 1:56 PM, Bernhard Voelker wrote:
> >  If you don't care what's in the destination at all,
> >   why not just rm it before the copy?
> >
> > "--remove-destination" option is supposed to do?
> "info coreutils 'cp invocation'" says:
----
   But if I specify "-a" or "-r" those imply recursive.  Why has it been
assumed that recursive doesn't mean to remove files (and then empty directories)
on the target?

> > 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.
---
        But if combined with "recursive"?  There's also the -T
option which says to treat the destination as a "file" and not a "dir" --
which could be construed as a deliberate choice on the part of the user
to circumvent restrictions on directory removal -- i.e. specifically
since its intent is to ignore the fact that the target is a directory and
to treat it as a file.


> 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
----
    That was true until various options (and restrictions) were added.
"-f" used to be more forceful about removing obstacles (though I can't say
it ever used to override directory restrictions).  But adding to it's copy
'mission', --update, and --remove-destination, but gave a basis for expanding
the definition of cp.  As for 'rsync', it's speed is *comparatively* abysmal
for local-to-local copies.  For that matter, 'cp' could _relearn_ a thing
or two from 'dd' when it comes to speed.  Used to be that cp was nearly as
fast as 'dd', but now that often doesn't seem to be the case.

    I'm fine with the idea of requiring a '__GNU_ENHANCEMENTS__=[list]'
option in the ENV, or consulting an "rc" file in
something like (~/.rc/Gnu/<package|tool>|/etc/Gnu/coreutils) that
could list areas to override restrictions & feature removals like:
(cp_dir_restrictions,rm_dot_override[etc] to restore or allow
enhancements beyond the growing, posix-restrictions.  Even a
posix=pre2003 would be useful, since it was about the 2003 updates
that started changing posix from descriptive to proscriptive.

   Please remember the idea behind things like 'ksh' and 'bash' (bourne-again)
were to allow features not in the original posix spec --- many of which posix
eventually accepted.  If there is nothing that provides an outlet for these,
posix will only devolve instead of evolve.  FSF/Gnu used to offer evolutionary
options over posix -- but now... it seems fsf/gnu has decided to submit to
the posix restrictions as a ceiling.  I still assert that any posix rules
that go beyond the original POSIX mission statement to be Descriptive
(or to provide for minimum requirements/features) that move into *proscriptive*,
or disallowal of features is, by definition outside the bounds of the
original POSIX and shouldn't really be abusing the name (I *liked* POSIX up
until it started removing features!)....


> Have a nice day,
---
Cheers!