Re: bug in copy-directory

[Michael Albinus]

Chong Yidong <address@hidden> writes:

> Stefan Monnier <address@hidden> writes:
>
>> I don't think there's a traditional C-level equivalent to `cp', but at
>> least for `mv', the C-level API (aka `rename') does not behave like
>> `mv', but instead signals an error if the destination is
>> a pre-existing directory.
>>
>> As Lennart points out, the semantics of `rename' are a bit less magical,
>> which tends to work well when you care about race-conditions and other
>> fun stuff.  OTOH out `copy-file' behaves like `cp', so I guess it's OK
>> for copy-directory to also always behave like `cp' even for
>> non-interactive uses.
>
> I've commited the patch to the branch.  Dired seems to still work fine.

Sorry for coming in late.

A year ago, there was the related Bug#5343. I've fixed that.

Your patch breaks recursive copy now. Extend the use case from that bug
report:

- Create directory /tmp/test
- Create directory /tmp/test/test
- Create file /tmp/test/a
- Create file /tmp/test/test/b

- Apply (copy-directory "/tmp/test" "~/")
  Everything is fine

- Apply again (copy-directory "/tmp/test" "~/")
  The target directory structure is broken.

> I haven't checked whether the Tramp handlers need fixing, though.

When possible, Tramp will use native means for recursive copy. Try
(copy-directory "/tmp/test" "/rsync::~/")

I would like to keep this behaviour.

Best regards, Michael.