GNU bug report logs - #5343
23.1.91; recursive directory copying is broken

Previous Next

Package: emacs;

Reported by: Stephen Berman <stephen.berman <at> gmx.net>

Date: Fri, 8 Jan 2010 23:24:02 UTC

Severity: normal

Done: Michael Albinus <michael.albinus <at> gmx.de>

Bug is archived. No further changes may be made.

Full log

View this message in rfc822 format

From: Lennart Borgman <lennart.borgman <at> gmail.com>
To: Stephen Berman <stephen.berman <at> gmx.net>, 5343 <at> debbugs.gnu.org
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 <at> gmx.net> wrote:
> On Sat, 09 Jan 2010 00:14:58 +0100 Stephen Berman <stephen.berman <at> 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 \"..\".")
This bug report was last modified 15 years and 130 days ago.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.