[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#5343: 23.1.91; recursive directory copying is broken
From: |
Lennart Borgman |
Subject: |
bug#5343: 23.1.91; recursive directory copying is broken |
Date: |
Sun, 10 Jan 2010 03:14:48 +0100 |
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 \"..\".")