bug#59986: 30.0.50; Can't trash file with broken symbolic link

bug#59986: 30.0.50; Can't trash file with broken symbolic link

[Jean Louis]

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/

bug#59986: 30.0.50; Can't trash file with broken symbolic link

[Michael Heerdegen]

Jean Louis <bugs@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.

bug#59986: 30.0.50; Can't trash file with broken symbolic link

[Jean Louis]

* Michael Heerdegen <michael_heerdegen@web.de> [2022-12-13 06:52]:
> Jean Louis <bugs@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/

bug#59986: 30.0.50; Can't trash file with broken symbolic link

[Eli Zaretskii]

> Cc: 59986@debbugs.gnu.org
> Date: Tue, 13 Dec 2022 11:00:11 +0300
> From: Jean Louis <bugs@gnu.support>
> 
> * Michael Heerdegen <michael_heerdegen@web.de> [2022-12-13 06:52]:
> > Jean Louis <bugs@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?

bug#59986: 30.0.50; Can't trash file with broken symbolic link

[Jean Louis]

* Eli Zaretskii <eliz@gnu.org> [2022-12-13 15:43]:
> > Cc: 59986@debbugs.gnu.org
> > Date: Tue, 13 Dec 2022 11:00:11 +0300
> > From: Jean Louis <bugs@gnu.support>
> > 
> > * Michael Heerdegen <michael_heerdegen@web.de> [2022-12-13 06:52]:
> > > Jean Louis <bugs@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/

bug#59986: 30.0.50; Can't trash file with broken symbolic link

[Eli Zaretskii]

> Date: Tue, 13 Dec 2022 16:49:55 +0300
> From: Jean Louis <bugs@gnu.support>
> Cc: michael_heerdegen@web.de, 59986@debbugs.gnu.org
> 
> * Eli Zaretskii <eliz@gnu.org> [2022-12-13 15:43]:
> > > Cc: 59986@debbugs.gnu.org
> > > Date: Tue, 13 Dec 2022 11:00:11 +0300
> > > From: Jean Louis <bugs@gnu.support>
> > > 
> > > * Michael Heerdegen <michael_heerdegen@web.de> [2022-12-13 06:52]:
> > > > Jean Louis <bugs@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.

bug#59986: 30.0.50; Can't trash file with broken symbolic link

[Jean Louis]

* Eli Zaretskii <eliz@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/

bug#59986: 30.0.50; Can't trash file with broken symbolic link

[Eli Zaretskii]

> Date: Tue, 13 Dec 2022 22:24:52 +0300
> From: Jean Louis <bugs@gnu.support>
> Cc: michael_heerdegen@web.de, 59986@debbugs.gnu.org
> 
> * Eli Zaretskii <eliz@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?

bug#59986: 30.0.50; Can't trash file with broken symbolic link

[Michael Heerdegen]

Eli Zaretskii <eliz@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.

bug#59986: 30.0.50; Can't trash file with broken symbolic link

[Eli Zaretskii]

> From: Michael Heerdegen <michael_heerdegen@web.de>
> Cc: Jean Louis <bugs@gnu.support>,  59986@debbugs.gnu.org
> Date: Thu, 15 Dec 2022 01:13:04 +0100
> 
> Eli Zaretskii <eliz@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.

bug#59986: 30.0.50; Can't trash file with broken symbolic link

[Jean Louis]

* Eli Zaretskii <eliz@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/

bug#59986: 30.0.50; Can't trash file with broken symbolic link

[Eli Zaretskii]

> Date: Thu, 15 Dec 2022 17:54:32 +0300
> From: Jean Louis <bugs@gnu.support>
> Cc: Michael Heerdegen <michael_heerdegen@web.de>, bugs@gnu.support,
>   59986@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)

bug#59986: 30.0.50; Can't trash file with broken symbolic link

[Jean Louis]

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/

bug#59986: 30.0.50; Can't trash file with broken symbolic link

[Eli Zaretskii]

> Date: Fri, 16 Dec 2022 09:39:31 +0300
> From: Jean Louis <bugs@gnu.support>
> Cc: michael_heerdegen@web.de, 59986@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.