bug#5343: 23.1.91; recursive directory copying is broken

[Lennart Borgman]

On Sat, Jan 9, 2010 at 10:53 PM, Stephen Berman <stephen.berman@gmx.net> wrote:
> On Sat, 09 Jan 2010 00:14:58 +0100 Stephen Berman <stephen.berman@gmx.net> 
> wrote:
>
>> 1. emacs -Q
>> 2. Make a directory /tmp/test, add to it a file named "a" and a
>>    directory named "test", and add to /tmp/test/test a file named "b".
>> 3. Type `M-x copy-directory RET /tmp/test RET ~ RET' to copy /tmp/test
>>    recursively to ~.
>> 4. Type `C-x d' and at the prompt `~' to visit ~ in Dired, put the
>>    cursor on the directory "test" and type `i' to open "test" as a
>>    subdirectory.  This is the result:
>>
>>   /home/steve/test:
>>   total used in directory 16 available 7794948
>>   -rw-r--r--  1 steve users    4 2010-01-08 23:57 a
>>   -rw-r--r--  1 steve users    7 2010-01-08 23:57 b
>
> This is due to the following code in copy-directory:
>
>    (if (and (file-directory-p newname)
>             (not (string-equal (file-name-nondirectory directory)
>                                (file-name-nondirectory newname))))
>        (setq newname
>              (expand-file-name (file-name-nondirectory directory) newname)))
>
> Specifically, the equality check prevents newname from being changed
> from "home/steve/test" to "home/steve/test/test".  Removing this check,
> as in the below patch, fixes the above breakage.  I don't see any real
> problem this check prevents, but maybe I'm overlooking something.


The check looks strange to me. I wonder if the intention really was to
prevent copying a directory tree into a subdirectory below itself? But
if so, should not the check be a bit different?


BTW, I looked at the variable `directory-files-no-dot-files-regexp'. I
minor issue, but should it not be

(defconst directory-files-no-dot-files-regexp
  "^\\(?:[^.]\\|\\.\\(?:[^.]\\|\\..\\)\\)"
  "Regexp of file names excluging \".\" an \"..\".")