emacs-bug-tracker
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[debbugs-tracker] bug#28792: closed (26.0.60; Deleting to a custom trash


From: GNU bug Tracking System
Subject: [debbugs-tracker] bug#28792: closed (26.0.60; Deleting to a custom trash directory in Dired gives error)
Date: Thu, 12 Oct 2017 21:42:02 +0000

Your message dated Thu, 12 Oct 2017 21:41:28 +0000
with message-id <address@hidden>
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
address@hidden)


-- 
28792: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=28792
GNU Bug Tracking System
Contact address@hidden with problems
--- Begin Message --- Subject: 26.0.60; Deleting to a custom trash directory in Dired gives error Date: Thu, 12 Oct 2017 03:26:26 +0000
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


--- End Message ---
--- Begin Message --- Subject: Re: bug#28792: 26.0.60; Deleting to a custom trash directory in Dired gives error Date: Thu, 12 Oct 2017 21:41:28 +0000
On Thu, Oct 12, 2017 at 4:25 PM Paul Eggert <address@hidden> wrote:
On 10/12/2017 08:27 AM, Andreas Schwab wrote:
> rename-file now refuses to copy directory across
> file systems unless the target name ends in a slash.

Thanks for the diagnosis. This is an unintended consequence of the
race-condition patch for rename-file that I installed last month. I
installed the attached patch into the emacs-26 branch to fix the bug.

Awesome! Thank you! I confirm the bug fix. 
--

Kaushal Modi


--- End Message ---

reply via email to

[Prev in Thread] Current Thread [Next in Thread]