GNU bug report logs - #59986
30.0.50; Can't trash file with broken symbolic link

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 59986 in the body.
You can then email your comments to 59986 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Jean Louis <bugs <at> gnu.support>
To: bug-gnu-emacs <at> gnu.org
Subject: 30.0.50; Can't trash file with broken symbolic link
Date: Mon, 12 Dec 2022 09:51:52 +0300

I am deleting files by using trash. My Trash is in
/home/data1/protected/tmp/Trash

In the directory:

/home/data1/protected/.mozilla/iceweasel/rzwnn0b0.default-release-2/

I have the following file:

D lrwxrwxrwx 1   20 Mar 24  2022 lock -> 217.170.207.13:+7513

which is:

lock: broken symbolic link to 217.170.207.13:+7513

and by marking it for deletion and trying to delete by moving to Trash,
I get the message:

file-already-exists: File already exists: /home/data1/protected/tmp/Trash/lock

Because in the Trash directory I have the following file:

  /home/data1/protected/tmp/Trash:
  lrwxrwxrwx 1    21 Dec 11 07:36 lock -> 217.170.207.13:+24763

which is:

lock: broken symbolic link to 217.170.207.13:+24763



In GNU Emacs 30.0.50 (build 1, x86_64-pc-linux-gnu, X toolkit, cairo
 version 1.17.6, Xaw3d scroll bars) of 2022-12-10 built on
 protected.rcdrun.com
Repository revision: fbbf3610fd5b27873e13cfd7702d5b0bbb15c2f8
Repository branch: master
Windowing system distributor 'The X.Org Foundation', version 11.0.12101004
System Description: Parabola GNU/Linux-libre

Configured using:
 'configure --with-x-toolkit=lucid'

Configured features:
ACL CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GPM GSETTINGS HARFBUZZ JPEG
JSON LCMS2 LIBOTF LIBSYSTEMD LIBXML2 M17N_FLT MODULES NOTIFY INOTIFY
PDUMPER PNG RSVG SECCOMP SOUND SQLITE3 THREADS TIFF TOOLKIT_SCROLL_BARS
WEBP X11 XAW3D XDBE XIM XINPUT2 XPM LUCID ZLIB

Important settings:
  value of $LC_ALL: en_US.UTF-8
  value of $LANG: de_DE.UTF-8
  value of $XMODIFIERS: @im=exwm-xim
  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
  line-number-mode: t
  indent-tabs-mode: t
  transient-mark-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t

Load-path shadows:
None found.

Features:
(shadow sort mail-extr emacsbug message mailcap yank-media puny dired
dired-loaddefs rfc822 mml mml-sec password-cache epa derived epg rfc6068
epg-config gnus-util text-property-search time-date subr-x mm-decode
mm-bodies mm-encode mail-parse rfc2231 mailabbrev gmm-utils mailheader
cl-loaddefs cl-lib sendmail rfc2047 rfc2045 ietf-drums mm-util
mail-prsvr mail-utils rmc iso-transl tooltip cconv 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 nadvice seq simple cl-generic
indonesian philippine 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 abbrev obarray oclosure cl-preloaded button loaddefs
theme-loaddefs faces cus-face macroexp files window text-properties
overlay sha1 md5 base64 format env code-pages mule custom widget keymap
hashtable-print-readable backquote threads dbusbind inotify lcms2
dynamic-setting system-font-setting font-render-setting cairo x-toolkit
xinput2 x multi-tty make-network-process emacs)

Memory information:
((conses 16 39079 4758)
 (symbols 48 5192 2)
 (strings 32 14313 1652)
 (string-bytes 1 403139)
 (vectors 16 10438)
 (vector-slots 8 158928 10100)
 (floats 8 40 19)
 (intervals 56 256 0)
 (buffers 984 11))

-- 
Jean

Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns

In support of Richard M. Stallman
https://stallmansupport.org/

Message #8 received at 59986 <at> debbugs.gnu.org (full text, mbox):

From: Michael Heerdegen <michael_heerdegen <at> web.de>
To: Jean Louis <bugs <at> gnu.support>
Cc: 59986 <at> debbugs.gnu.org
Subject: Re: bug#59986: 30.0.50; Can't trash file with broken symbolic link
Date: Tue, 13 Dec 2022 04:51:24 +0100

Jean Louis <bugs <at> gnu.support> writes:

> file-already-exists: File already exists: /home/data1/protected/tmp/Trash/lock

Thanks.  This looks like #47135 from you:

https://lists.nongnu.org/archive/html/bug-gnu-emacs/2021-03/msg01305.html

Looks identical, but Lars said he had fixed that.  Are you maybe able to
find out why his fix doesn't work for you in your case?

Michael.

Message #11 received at 59986 <at> debbugs.gnu.org (full text, mbox):

From: Jean Louis <bugs <at> gnu.support>
To: Michael Heerdegen <michael_heerdegen <at> web.de>
Cc: 59986 <at> debbugs.gnu.org
Subject: Re: bug#59986: 30.0.50; Can't trash file with broken symbolic link
Date: Tue, 13 Dec 2022 11:00:11 +0300

* Michael Heerdegen <michael_heerdegen <at> web.de> [2022-12-13 06:52]:
> Jean Louis <bugs <at> gnu.support> writes:
> 
> > file-already-exists: File already exists: /home/data1/protected/tmp/Trash/lock
> 
> Thanks.  This looks like #47135 from you:
> 
> https://lists.nongnu.org/archive/html/bug-gnu-emacs/2021-03/msg01305.html
> 
> Looks identical, but Lars said he had fixed that.  Are you maybe able to
> find out why his fix doesn't work for you in your case?

I cannoft (easily) find out why that does not work, and how it was
fixed and where. In the bug description I have tried to describe the
conditions for those who know how to debug it, to help them.

-- 
Jean

Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns

In support of Richard M. Stallman
https://stallmansupport.org/

Message #14 received at 59986 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Jean Louis <bugs <at> gnu.support>
Cc: michael_heerdegen <at> web.de, 59986 <at> debbugs.gnu.org
Subject: Re: bug#59986: 30.0.50; Can't trash file with broken symbolic link
Date: Tue, 13 Dec 2022 14:42:27 +0200

> Cc: 59986 <at> debbugs.gnu.org
> Date: Tue, 13 Dec 2022 11:00:11 +0300
> From: Jean Louis <bugs <at> gnu.support>
> 
> * Michael Heerdegen <michael_heerdegen <at> web.de> [2022-12-13 06:52]:
> > Jean Louis <bugs <at> gnu.support> writes:
> > 
> > > file-already-exists: File already exists: /home/data1/protected/tmp/Trash/lock
> > 
> > Thanks.  This looks like #47135 from you:
> > 
> > https://lists.nongnu.org/archive/html/bug-gnu-emacs/2021-03/msg01305.html
> > 
> > Looks identical, but Lars said he had fixed that.  Are you maybe able to
> > find out why his fix doesn't work for you in your case?
> 
> I cannoft (easily) find out why that does not work, and how it was
> fixed and where. In the bug description I have tried to describe the
> conditions for those who know how to debug it, to help them.

Is the recipe of bug#47135 working for you now?  Or does it still
fail?

Message #17 received at 59986 <at> debbugs.gnu.org (full text, mbox):

From: Jean Louis <bugs <at> gnu.support>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: michael_heerdegen <at> web.de, 59986 <at> debbugs.gnu.org
Subject: Re: bug#59986: 30.0.50; Can't trash file with broken symbolic link
Date: Tue, 13 Dec 2022 16:49:55 +0300

* Eli Zaretskii <eliz <at> gnu.org> [2022-12-13 15:43]:
> > Cc: 59986 <at> debbugs.gnu.org
> > Date: Tue, 13 Dec 2022 11:00:11 +0300
> > From: Jean Louis <bugs <at> gnu.support>
> > 
> > * Michael Heerdegen <michael_heerdegen <at> web.de> [2022-12-13 06:52]:
> > > Jean Louis <bugs <at> gnu.support> writes:
> > > 
> > > > file-already-exists: File already exists: /home/data1/protected/tmp/Trash/lock
> > > 
> > > Thanks.  This looks like #47135 from you:
> > > 
> > > https://lists.nongnu.org/archive/html/bug-gnu-emacs/2021-03/msg01305.html
> > > 
> > > Looks identical, but Lars said he had fixed that.  Are you maybe able to
> > > find out why his fix doesn't work for you in your case?
> > 
> > I cannoft (easily) find out why that does not work, and how it was
> > fixed and where. In the bug description I have tried to describe the
> > conditions for those who know how to debug it, to help them.
> 
> Is the recipe of bug#47135 working for you now?  Or does it still
> fail?

https://debbugs.gnu.org/cgi/bugreport.cgi?bug=47135

I can't locate on that page what you mean with recipe? Which one?

Jean

Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns

In support of Richard M. Stallman
https://stallmansupport.org/

Message #20 received at 59986 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Jean Louis <bugs <at> gnu.support>
Cc: michael_heerdegen <at> web.de, 59986 <at> debbugs.gnu.org
Subject: Re: bug#59986: 30.0.50; Can't trash file with broken symbolic link
Date: Tue, 13 Dec 2022 16:44:38 +0200

> Date: Tue, 13 Dec 2022 16:49:55 +0300
> From: Jean Louis <bugs <at> gnu.support>
> Cc: michael_heerdegen <at> web.de, 59986 <at> debbugs.gnu.org
> 
> * Eli Zaretskii <eliz <at> gnu.org> [2022-12-13 15:43]:
> > > Cc: 59986 <at> debbugs.gnu.org
> > > Date: Tue, 13 Dec 2022 11:00:11 +0300
> > > From: Jean Louis <bugs <at> gnu.support>
> > > 
> > > * Michael Heerdegen <michael_heerdegen <at> web.de> [2022-12-13 06:52]:
> > > > Jean Louis <bugs <at> gnu.support> writes:
> > > > 
> > > > > file-already-exists: File already exists: /home/data1/protected/tmp/Trash/lock
> > > > 
> > > > Thanks.  This looks like #47135 from you:
> > > > 
> > > > https://lists.nongnu.org/archive/html/bug-gnu-emacs/2021-03/msg01305.html
> > > > 
> > > > Looks identical, but Lars said he had fixed that.  Are you maybe able to
> > > > find out why his fix doesn't work for you in your case?
> > > 
> > > I cannoft (easily) find out why that does not work, and how it was
> > > fixed and where. In the bug description I have tried to describe the
> > > conditions for those who know how to debug it, to help them.
> > 
> > Is the recipe of bug#47135 working for you now?  Or does it still
> > fail?
> 
> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=47135
> 
> I can't locate on that page what you mean with recipe? Which one?

I mean your original description that opened the bug.

Message #23 received at 59986 <at> debbugs.gnu.org (full text, mbox):

From: Jean Louis <bugs <at> gnu.support>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: michael_heerdegen <at> web.de, 59986 <at> debbugs.gnu.org
Subject: Re: bug#59986: 30.0.50; Can't trash file with broken symbolic link
Date: Tue, 13 Dec 2022 22:24:52 +0300

* Eli Zaretskii <eliz <at> gnu.org> [2022-12-13 17:45]:
> > https://debbugs.gnu.org/cgi/bugreport.cgi?bug=47135
> > 
> > I can't locate on that page what you mean with recipe? Which one?
> 
> I mean your original description that opened the bug.

For original one, I cannot know.

Now I see that if symbolic link exists in Trash, such as:

1661195272884.jpg -> hyperscope/7/3/9/8/7/2022/11/2022-11-27/1661195272884.jpg

then the same symbolic link from ~/ cannot be deleted by moving to
Trash because it will say that file already exists.

Jean

Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns

In support of Richard M. Stallman
https://stallmansupport.org/

Message #26 received at 59986 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Jean Louis <bugs <at> gnu.support>
Cc: michael_heerdegen <at> web.de, 59986 <at> debbugs.gnu.org
Subject: Re: bug#59986: 30.0.50; Can't trash file with broken symbolic link
Date: Wed, 14 Dec 2022 14:29:02 +0200

> Date: Tue, 13 Dec 2022 22:24:52 +0300
> From: Jean Louis <bugs <at> gnu.support>
> Cc: michael_heerdegen <at> web.de, 59986 <at> debbugs.gnu.org
> 
> * Eli Zaretskii <eliz <at> gnu.org> [2022-12-13 17:45]:
> > > https://debbugs.gnu.org/cgi/bugreport.cgi?bug=47135
> > > 
> > > I can't locate on that page what you mean with recipe? Which one?
> > 
> > I mean your original description that opened the bug.
> 
> For original one, I cannot know.

Meaning that you don't remember whether the file which was already in
Trash in bug#47135 was or wasn't a symlink?

Message #29 received at 59986 <at> debbugs.gnu.org (full text, mbox):

From: Michael Heerdegen <michael_heerdegen <at> web.de>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 59986 <at> debbugs.gnu.org, Jean Louis <bugs <at> gnu.support>
Subject: Re: bug#59986: 30.0.50; Can't trash file with broken symbolic link
Date: Thu, 15 Dec 2022 01:13:04 +0100

Eli Zaretskii <eliz <at> gnu.org> writes:

> Meaning that you don't remember whether the file which was already in
> Trash in bug#47135 was or wasn't a symlink?

AFAIU it had been - the original report says:

| In my trash there is this file:
|
|   lrwxrwxrwx 1  175 Jun 18  2019 Rock-and-Mineral-Identification.pdf -> /home/...

I think there is indeed a problem with those `file-exists-p' tests in
`move-file-to-trash' that check whether the file name to add (in the
trash) already exists: when that name is the existing name of a broken
symlink the result is `nil'.

Those tests probably need to handle symlinks specially (using
file-symlink-p I guess).

Michael.

Message #32 received at 59986 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Michael Heerdegen <michael_heerdegen <at> web.de>
Cc: 59986 <at> debbugs.gnu.org, bugs <at> gnu.support
Subject: Re: bug#59986: 30.0.50; Can't trash file with broken symbolic link
Date: Thu, 15 Dec 2022 09:12:16 +0200

> From: Michael Heerdegen <michael_heerdegen <at> web.de>
> Cc: Jean Louis <bugs <at> gnu.support>,  59986 <at> debbugs.gnu.org
> Date: Thu, 15 Dec 2022 01:13:04 +0100
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> > Meaning that you don't remember whether the file which was already in
> > Trash in bug#47135 was or wasn't a symlink?
> 
> AFAIU it had been - the original report says:
> 
> | In my trash there is this file:
> |
> |   lrwxrwxrwx 1  175 Jun 18  2019 Rock-and-Mineral-Identification.pdf -> /home/...

Sorry, I was confused when I wrote the question: I was actually
interested in the file being moved to trash, not the file already in
the trash.

Message #35 received at 59986 <at> debbugs.gnu.org (full text, mbox):

From: Jean Louis <bugs <at> gnu.support>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Michael Heerdegen <michael_heerdegen <at> web.de>, 59986 <at> debbugs.gnu.org,
 bugs <at> gnu.support
Subject: Re: bug#59986: 30.0.50; Can't trash file with broken symbolic link
Date: Thu, 15 Dec 2022 17:54:32 +0300

* Eli Zaretskii <eliz <at> gnu.org> [2022-12-15 10:12]:
> Sorry, I was confused when I wrote the question: I was actually
> interested in the file being moved to trash, not the file already in
> the trash.

If there is dangling symlink in Trash then even if the file to be
deleted to Trash exists and is not symlink, I get the same error
message:

To reproduce:

1. Create dangling symlink:

   $ ln -s something more

2. Delete the file `more' to Trash by using Emacs

3. Create new file

   $ touch more

4. Try deleting file `more' by moving to Trash, there is error:

   file-already-exists: File already exists: /home/data1/protected/tmp/Trash/more

--
Jean

Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns

In support of Richard M. Stallman
https://stallmansupport.org/

Message #38 received at 59986 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Jean Louis <bugs <at> gnu.support>
Cc: michael_heerdegen <at> web.de, 59986 <at> debbugs.gnu.org
Subject: Re: bug#59986: 30.0.50; Can't trash file with broken symbolic link
Date: Thu, 15 Dec 2022 18:07:45 +0200

> Date: Thu, 15 Dec 2022 17:54:32 +0300
> From: Jean Louis <bugs <at> gnu.support>
> Cc: Michael Heerdegen <michael_heerdegen <at> web.de>, bugs <at> gnu.support,
>   59986 <at> debbugs.gnu.org
> 
> If there is dangling symlink in Trash then even if the file to be
> deleted to Trash exists and is not symlink, I get the same error
> message:

Can you try the patch below and see if it solves the problem?

diff --git a/lisp/files.el b/lisp/files.el
index d785d4f..c74e7e8 100644
--- a/lisp/files.el
+++ b/lisp/files.el
@@ -8467,6 +8467,14 @@ trash--hexify-table
 
 (declare-function system-move-file-to-trash "w32fns.c" (filename))
 
+(defun file-exists-in-trash-p (filename)
+  "Return non-nil if FILENAME exists in the trash.
+
+This is like `file-exists-p', but it also returns non-nil
+if FILENAME is a dangling symlink, to allow trashing such files."
+  (or (file-exists-p filename)
+      (file-symlink-p filename)))
+
 (defun move-file-to-trash (filename)
   "Move the file (or directory) named FILENAME to the trash.
 When `delete-by-moving-to-trash' is non-nil, this function is
@@ -8497,7 +8505,7 @@ move-file-to-trash
 	   (unless (file-directory-p trash-dir)
 	     (make-directory trash-dir t))
 	   ;; Ensure that the trashed file-name is unique.
-	   (if (file-exists-p new-fn)
+	   (if (file-exists-in-trash-p new-fn)
 	       (let ((version-control t)
 		     (backup-directory-alist nil))
 		 (setq new-fn (car (find-backup-file-name new-fn)))))
@@ -8574,7 +8582,7 @@ move-file-to-trash
                  ;; We're checking further down whether the info file
                  ;; exists, but the file name may exist in the trash
                  ;; directory even if there is no info file for it.
-                 (when (file-exists-p
+                 (when (file-exists-in-trash-p
                         (file-name-concat trash-files-dir files-base))
                    (setq overwrite t
                          files-base (file-name-nondirectory
@@ -8612,7 +8620,7 @@ move-file-to-trash
 		 (let ((delete-by-moving-to-trash nil)
 		       (new-fn (file-name-concat trash-files-dir files-base)))
                    (if (or (not is-directory)
-                           (not (file-exists-p new-fn)))
+                           (not (file-exists-in-trash-p new-fn)))
                        (rename-file fn new-fn overwrite)
                      (copy-directory fn
                                      (file-name-as-directory new-fn)

Message #41 received at 59986 <at> debbugs.gnu.org (full text, mbox):

From: Jean Louis <bugs <at> gnu.support>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: michael_heerdegen <at> web.de, 59986 <at> debbugs.gnu.org
Subject: Re: bug#59986: 30.0.50; Can't trash file with broken symbolic link
Date: Fri, 16 Dec 2022 09:39:31 +0300

I have manually applied that patch as I do not know how to
apply it directly. Am I supposed to use `patch' command? 

I have tested your patch and it can delete dangling symlinks
and moves them to Trash. And I could observe it adds ~N~ to
file names, so it works well.

  lrwxrwxrwx 1    9 Dec 15 17:51 more -> something
  lrwxrwxrwx 1    9 Dec 16 09:37 more.~1~ -> something
  lrwxrwxrwx 1    9 Dec 16 09:37 more.~2~ -> something
  -rwxr-xr-x 1 1.5K Sep 15  2018 

Thanks much.


Jean

Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns

In support of Richard M. Stallman
https://stallmansupport.org/

Message #46 received at 59986-done <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Jean Louis <bugs <at> gnu.support>
Cc: michael_heerdegen <at> web.de, 59986-done <at> debbugs.gnu.org
Subject: Re: bug#59986: 30.0.50; Can't trash file with broken symbolic link
Date: Fri, 16 Dec 2022 17:56:25 +0200

> Date: Fri, 16 Dec 2022 09:39:31 +0300
> From: Jean Louis <bugs <at> gnu.support>
> Cc: michael_heerdegen <at> web.de, 59986 <at> debbugs.gnu.org
> 
> I have manually applied that patch as I do not know how to
> apply it directly. Am I supposed to use `patch' command? 
> 
> I have tested your patch and it can delete dangling symlinks
> and moves them to Trash. And I could observe it adds ~N~ to
> file names, so it works well.
> 
>   lrwxrwxrwx 1    9 Dec 15 17:51 more -> something
>   lrwxrwxrwx 1    9 Dec 16 09:37 more.~1~ -> something
>   lrwxrwxrwx 1    9 Dec 16 09:37 more.~2~ -> something
>   -rwxr-xr-x 1 1.5K Sep 15  2018 
> 
> Thanks much.

Thanks for testing.  I've now installed the fix on the emacs-29
branch, and I'm therefore closing this bug.

Previous Next

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