GNU bug report logs -
#28792
26.0.60; Deleting to a custom trash directory in Dired gives error
Previous Next
Reported by: Kaushal Modi <kaushal.modi <at> gmail.com>
Date: Thu, 12 Oct 2017 03:27:01 UTC
Severity: normal
Tags: fixed
Merged with 28519,
28828
Found in versions 26.0.50, 26.0.60, 27.0.50
Fixed in version 26.1
Done: Noam Postavsky <npostavs <at> users.sourceforge.net>
Bug is archived. No further changes may be made.
Full log
View this message in rfc822 format
[Message part 1 (text/plain, inline)]
Your message dated Sun, 15 Oct 2017 00:18:55 -0700
with message-id <a64099a0-53b9-a5c1-f5d4-3996c9972c63 <at> cs.ucla.edu>
and subject line Re: bug#28792: 26.0.60; Deleting to a custom trash directory in Dired gives error
has caused the debbugs.gnu.org bug report #28792,
regarding 26.0.60; Deleting to a custom trash directory in Dired gives error
to be marked as done.
(If you believe you have received this mail in error, please contact
help-debbugs <at> gnu.org.)
--
28792: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=28792
GNU Bug Tracking System
Contact help-debbugs <at> gnu.org with problems
[Message part 2 (message/rfc822, inline)]
[Message part 3 (text/plain, inline)]
Hello,
This seems to be a regression from emacs 25.x.
If I have set delete-by-moving-to-trash to t AND trash-directory to a
custom value (there's a qualifier though, read further), I get this error,
but that does not trigger backtrace even after toggle-debug-on-error!
=====
Trashing...
(file-error Non-regular file Is a directory /home/kmodi/.emacs.d/foo)
=====
I was though able to force a backtrace (shown below) after trying to
recreate the same error after evaluating:
(setq debug-on-message "Non-regular")
=====
Debugger entered--Lisp error: "(file-error Non-regular file Is a directory
/home/kmodi/.emacs.d/foo)\n"
message("%s" "(file-error Non-regular file Is a directory
/home/kmodi/.emacs.d/foo)\n")
dired-log-summary("1 of 1 deletion failed" ("/home/kmodi/.emacs.d/foo"))
dired-internal-do-deletions((("/home/kmodi/.emacs.d/foo" . 2827)) nil t)
dired-do-delete(nil)
funcall-interactively(dired-do-delete nil)
call-interactively(dired-do-delete nil nil)
command-execute(dired-do-delete)
=====
Here is the recipe to recreate this in emacs -Q:
1. First evaluate the below
(progn
(setq delete-by-moving-to-trash t)
(setq trash-directory
(let ((dir (concat temporary-file-directory
(getenv "USER") "/.trash_emacs/"))) ;Must end
with /
(mkdir dir :parents)
dir))
(setq debug-on-message "Non-regular"))
2. Now evaluate
;; CASE A
(let ((dir (concat user-emacs-directory "foo/")))
(mkdir dir :parents)
(dired (concat dir "..")))
Now when you move the point to the foo dir, hit D and type yes, you will
get the above pasted backtrace.
Now here is the qualifier piece.. the same error does not happen if I try
to delete a directory in the temporary-file-directory!
So when I evaluate:
;; CASE B
(let ((dir (concat temporary-file-directory "foo/")))
(mkdir dir :parents)
(dired (concat dir "..")))
Then move the point to the foo dir, hit D and type yes, the deletion
(trashing) of that foo directory happens fine without that error.
So with this, CASE A gives error, CASE B does not.
Here's a twist..
Now let's move the trash directory from temporary-file-directory to
user-emacs-directory .. eval the below:
(setq trash-directory
(let ((dir (concat user-emacs-directory "/.trash_emacs/"))) ;Must
end with /
(mkdir dir :parents)
dir))
NOW, CASE A above will work fine, and CASE B will give that error.
My machine is RHEL 6.6. And the drives are NFS mounts. So I don't know
which of the below is true:
- Gives an error if the ORIG directory and TRASH directory are on possibly
different mounts.
- Gives an error if the ORIG and TRASH directory do not have the same root
directory (/home vs /tmp in the above example).
So that is the main bug report.
Side bug report on the fact that the below error does not generate a
backtrace with toggle-debug-on-error.. why is that?
(file-error Non-regular file Is a directory /home/kmodi/.emacs.d/foo)
(Thanks for reading through this whole bug report.. hopefully someone is
able to reproduce this issue and fix it.)
-----
In GNU Emacs 26.0.60 (build 26, x86_64-pc-linux-gnu, GTK+ Version 2.24.23)
of 2017-10-11
Repository revision: 419a371f8b3d4ba200770be07136f909c7984ece
Windowing system distributor 'The X.Org Foundation', version 11.0.60900000
System Description: Red Hat Enterprise Linux Workstation release 6.6
(Santiago)
Configured using:
'configure --with-modules
--prefix=/home/kmodi/usr_local/apps/6/emacs/emacs-26
'--program-transform-name=s/^ctags$/ctags_emacs/'
'CPPFLAGS=-I/home/kmodi/usr_local/6/include -I/usr/include/freetype2
-I/usr/include' 'CFLAGS=-ggdb3 -O0' 'CXXFLAGS=-ggdb3 -O0'
'LDFLAGS=-L/home/kmodi/usr_local/6/lib -L/home/kmodi/usr_local/6/lib64
-ggdb3''
Configured features:
XPM JPEG TIFF GIF PNG RSVG IMAGEMAGICK SOUND GPM DBUS GSETTINGS NOTIFY
ACL LIBSELINUX GNUTLS LIBXML2 FREETYPE LIBOTF XFT ZLIB
TOOLKIT_SCROLL_BARS GTK2 X11 MODULES
Important settings:
value of $LANG: en_US.UTF-8
value of $XMODIFIERS: @im=none
locale-coding-system: utf-8-unix
--
Kaushal Modi
[Message part 4 (text/html, inline)]
[Message part 5 (message/rfc822, inline)]
Kaushal Modi wrote:
> I confirm the bug fix.
Thanks for checking; closing the bug report.
This bug report was last modified 7 years and 215 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.