--- Begin Message ---
|
Subject: |
28.2; Copying files in dired |
|
Date: |
Mon, 31 Oct 2022 08:25:27 +0100 |
|
User-agent: |
mu4e 1.8.10; emacs 28.2 |
I've discovered what seems might be a bug in the functions
dired-do-copy
and dired-do-rename. Copying or renaming files fails when
attempting to
merge directories. Consider the following:
1. Start emacs via emacs -Q
2. Navigate with dired to some safe, user-writable directory, such
as
your home directory.
3. Create two directories called testA and testB, with
dired-create-directory for instance.
4. Inside ~/testA create another subdirectory called
foo.
5. Create a file ~/testA/foo/bar and enter
some example text.
6. In a dired buffer visiting ~/testA, mark the foo directory.
7. Copy the directory to the other directory, via dired-do-copy.
This
should prompt for a destination, ~/testA/ by default, so press
backspace
twice and complete the destination to ~/testB/ and press enter.
8. Now modify the file ~/testB/foo/bar and save it. (This step is
actually optional as the outcome won't change either way.)
9. Switch back to the dired buffer visiting ~/testA/ and attempt
to copy
the foo directory to ~/testB/ again as in step 7.
10. You will be prompted to overwrite, press y or ! here to do so.
Now
you should be prompted to copy recursively, so type in yes and
press
enter.
11. The command fails with the error: Copy:
'/home/clock/testA/foo' to '/home/clock/testB/' failed:
(file-already-exists File exists /home/clock/testB/foo)
My expectation here is that dired would recurse into the foo
directory,
and in the case that you have pressed y, it should ask if you
would like
to overwrite the file bar, and if you have pressed !, you
shouldn't be
prompted and the file should be overwritten. Furthermore, if the
contents of ~/testA/foo differ further, with more subdirectories
and
files, those files should all be copied over as with the behavior
of cp
-r in bash. If you perform these same steps up to step 9, but in
step 9
you use dired-do-rename, the resulting error changes to this:
Move: '/home/clock/testA/foo' to '/home/clock/testB/foo' failed:
(file-error Renaming Directory not empty /home/clock/testA/foo
/home/clock/testB/foo)
In GNU Emacs 28.2 (build 2, x86_64-unknown-linux-gnu, GTK+ Version
3.24.34, cairo version 1.16.0)
of 2022-09-13 built on a-fsn-de
Windowing system distributor 'The X.Org Foundation', version
11.0.12101004
System Description: Void Linux
Configured using:
'configure --with-x-toolkit=gtk3 --with-xwidgets --prefix=/usr
--sysconfdir=/etc --sbindir=/usr/bin --bindir=/usr/bin
--mandir=/usr/share/man --infodir=/usr/share/info
--localstatedir=/var
--host=x86_64-unknown-linux-gnu --build=x86_64-unknown-linux-gnu
'--libdir=${exec_prefix}/lib64' --with-file-notification=inotify
--with-modules --with-jpeg --with-tiff --with-gif --with-png
--with-xpm
--with-rsvg --without-imagemagick --with-xml2 --with-gnutls
--with-sound --with-m17n-flt --with-json --with-harfbuzz
--with-cairo
--with-libgmp --with-native-compilation 'CFLAGS=-fno-PIE
-mtune=generic
-O2 -pipe -g -fdebug-prefix-map=/builddir/emacs-28.2=.'
'CPPFLAGS= '
'LDFLAGS=-no-pie -Wl,--as-needed ''
Configured features:
ACL CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GSETTINGS HARFBUZZ
JPEG JSON
LCMS2 LIBOTF LIBXML2 M17N_FLT MODULES NATIVE_COMP NOTIFY INOTIFY
PDUMPER
PNG RSVG SECCOMP SOUND THREADS TIFF TOOLKIT_SCROLL_BARS X11 XDBE
XIM XPM
XWIDGETS GTK3 ZLIB
Important settings:
value of $LC_COLLATE: C
value of $LANG: en_US.UTF-8
locale-coding-system: utf-8-unix
Major mode: Lisp Interaction
Minor modes in effect:
tooltip-mode: t
global-eldoc-mode: t
eldoc-mode: t
show-paren-mode: t
electric-indent-mode: t
mouse-wheel-mode: t
tool-bar-mode: t
menu-bar-mode: t
file-name-shadow-mode: t
global-font-lock-mode: t
font-lock-mode: t
blink-cursor-mode: t
auto-composition-mode: t
auto-encryption-mode: t
auto-compression-mode: t
line-number-mode: t
indent-tabs-mode: t
transient-mark-mode: t
Load-path shadows:
None found.
Features:
(shadow sort mail-extr emacsbug message rmc puny dired
dired-loaddefs
rfc822 mml mml-sec epa derived epg rfc6068 epg-config gnus-util
rmail
rmail-loaddefs auth-source eieio eieio-core eieio-loaddefs
password-cache json map text-property-search mm-decode mm-bodies
mm-encode mail-parse rfc2231 mailabbrev gmm-utils mailheader
sendmail
rfc2047 rfc2045 ietf-drums mm-util mail-prsvr mail-utils apropos
comp
comp-cstr warnings rx cl-seq cl-macs cl-extra help-mode seq
byte-opt gv
bytecomp byte-compile cconv time-date subr-x cl-loaddefs cl-lib
iso-transl tooltip eldoc paren electric uniquify ediff-hook
vc-hooks
lisp-float-type elisp-mode mwheel term/x-win x-win term/common-win
x-dnd
tool-bar dnd fontset image regexp-opt fringe tabulated-list
replace
newcomment text-mode lisp-mode prog-mode register page tab-bar
menu-bar
rfn-eshadow isearch easymenu timer select scroll-bar mouse
jit-lock
font-lock syntax font-core term/tty-colors frame minibuffer
cl-generic
cham georgian utf-8-lang misc-lang vietnamese tibetan thai
tai-viet lao
korean japanese eucjp-ms cp51932 hebrew greek romanian slovak
czech
european ethiopic indian cyrillic chinese composite emoji-zwj
charscript
charprop case-table epa-hook jka-cmpr-hook help simple abbrev
obarray
cl-preloaded nadvice button loaddefs faces cus-face macroexp files
window text-properties overlay sha1 md5 base64 format env
code-pages
mule custom widget hashtable-print-readable backquote threads
xwidget-internal dbusbind inotify lcms2 dynamic-setting
system-font-setting font-render-setting cairo move-toolbar gtk
x-toolkit
x multi-tty make-network-process native-compile emacs)
Memory information:
((conses 16 89023 9463)
(symbols 48 7940 1)
(strings 32 23961 4125)
(string-bytes 1 841821)
(vectors 16 18290)
(vector-slots 8 337377 23668)
(floats 8 32 33)
(intervals 56 307 0)
(buffers 992 13))
--- End Message ---
--- Begin Message ---
|
Subject: |
Re: bug#58919: 28.2; dired-copy-file-recursive fails to overwrite directory |
|
Date: |
Sat, 17 Dec 2022 14:40:09 -0800 |
|
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.4.2 |
On 12/17/22 01:52, Michael Albinus wrote:
Since file name handlers still raise an error in case DIR exists and
PARENTS is nil, we might see surprises in code assuming the new
behavior. I guess I'll add a change in tramp-*-handle-make-directory
like
--8<---------------cut here---------------start------------->8---
(if (and (null parents) (file-exists-p dir))
(if (>= emacs-major-version 29)
t
(tramp-error v 'file-already-exists dir)))
--8<---------------cut here---------------end--------------->8---
That doesn't look right, as there is no change as to whether
make-directory signals an error. Nor is there any change in behavior
when PARENTS is nil. The only change in behavior is when PARENTS is
non-nil and DIRECTORY already exists as a directory: in this case, Emacs
29 returns non-nil whereas earlier Emacs returns (undocumented) nil.
So I think all that it would be nice to do is make sure the handlers
ordinarily return nil, except that they return non-nil in the
abovementioned special case. If a handler currently signals an error, it
should continue to do so in the same way as it did before. Strictly
speaking, modifying the handlers in this way won't affect whether they
are compatible with Emacs 28- (since their return value is undocumented
there) nor will it affect whether they work in Emacs 29 (since Emacs 29
ignores their return value). But it might affect whether the handlers
will work with Emacs 30, which might start assuming the Emacs 29 API for
make-directory handlers.
Come to think of it, if an existing make-directory handler returns
non-nil now (which it is allowed to in Emacs 28 as the return value is
undocumented), then the proposed changes would sometimes have caused
make-directory to return that non-nil value to its caller, even when the
Emacs 29 doc says make-directory should return nil. As far as I know no
such make-directory handler does so now, but to be safe I installed the
attached additional patch to make sure Emacss 29 make-directory returns
nil in this situation. As the combined set of patches should fix the
original bug report I'm marking it as done.
In Emacs 30 we could remove this additional patch once we've fixed all
the handlers, along with omitting some of the other code that supports
calling Emacs 28-style handlers in Emacs 30 environments. Or we could
leave it in; there's no rush, I imagine.
0001-Don-t-assume-make-directory-handler-returns-nil.patch
Description: Text Data
--- End Message ---