bug#74674: 30.0.91; Can't delete an empty symlink when trashing is enabled for root

bug#74674: 30.0.91; Can't delete an empty symlink when trashing is enabled for root

[the_wurfkreuz via Bug reports for GNU Emacs, the Swiss army knife of text editors]

[-- Attachment #1: Type: text/plain, Size: 793 bytes --]

If I evaluate the code to enable trashing for root and try to delete an empty symbolic link from Eshell, I get:
File is missing: /path/to/link

Steps to reproduce:

1. emacs -Q
2. M-: (connection-local-set-profile-variables 'remote-trash-directory '((trash-directory . "/sudo::~/.local/share/trash/")))
3. M-: (connection-local-set-profiles `(:application tramp :protocol "sudo" :machine ,(system-name)) 'remote-trash-directory)
4. M-x eshell
5. (require 'em-tramp)
6. (setq delete-by-moving-to-trash t)
7. sudo touch /usr/local/bin/test-file
8. ln -s /sudo::/usr/local/bin/test-file /sudo::/usr/local/bin/test-file-line
9. sudo rm /usr/local/bin/test-file
10. sudo rm /usr/local/bin/test-file-line

"File is missing: /usr/local/bin/test-file-link".

Expected behavior:

I'm able to delete it.

[-- Attachment #2: Type: text/html, Size: 1383 bytes --]

bug#74674: (No Subject)

[the_wurfkreuz via Bug reports for GNU Emacs, the Swiss army knife of text editors]

[-- Attachment #1: Type: text/plain, Size: 356 bytes --]

The problem got even more complicated. Now i'm trying to just delete any file, and i can't do that whether i have trashing enabled or not:

~/.emacs.d $ (require 'em-tramp)
em-tramp
~/.emacs.d [1] $ eshell/sudo touch /usr/local/bin/test-file
~/.emacs.d $ eshell/sudo rm /usr/local/bin/test-fileRemoving old name: Permission denied, /usr/local/bin/test-file

[-- Attachment #2: Type: text/html, Size: 662 bytes --]

bug#74674: (No Subject)

[the_wurfkreuz via Bug reports for GNU Emacs, the Swiss army knife of text editors]

[-- Attachment #1: Type: text/plain, Size: 56 bytes --]

I can delete the file if i just use /usr/bin/rm instead.

[-- Attachment #2: Type: text/html, Size: 231 bytes --]

bug#74674: 30.0.91; Can't delete an empty symlink when trashing is enabled for root

[Stefan Kangas]

the_wurfkreuz via "Bug reports for GNU Emacs, the Swiss army knife of
text editors" <bug-gnu-emacs@gnu.org> writes:

> If I evaluate the code to enable trashing for root and try to delete an empty symbolic link from Eshell, I get:
> File is missing: /path/to/link
>
> Steps to reproduce:
>
> 1. emacs -Q
> 2. M-: (connection-local-set-profile-variables 'remote-trash-directory '((trash-directory . "/sudo::~/.local/share/trash/")))
> 3. M-: (connection-local-set-profiles `(:application tramp :protocol "sudo" :machine ,(system-name)) 'remote-trash-directory)
> 4. M-x eshell
> 5. (require 'em-tramp)
> 6. (setq delete-by-moving-to-trash t)
> 7. sudo touch /usr/local/bin/test-file
> 8. ln -s /sudo::/usr/local/bin/test-file /sudo::/usr/local/bin/test-file-line
> 9. sudo rm /usr/local/bin/test-file
> 10. sudo rm /usr/local/bin/test-file-line
>
> "File is missing: /usr/local/bin/test-file-link".
>
> Expected behavior:
>
> I'm able to delete it.

I'm copying in Jim Porter.

bug#74674: (No Subject)

[Jim Porter]

On 12/4/2024 12:47 PM, the_wurfkreuz via Bug reports for GNU Emacs, the 
Swiss army knife of text editors wrote:
> The problem got even more complicated. Now i'm trying to just delete any 
> file, and i can't do that whether i have trashing enabled or not:
> 
> ~/.emacs.d $ (require 'em-tramp)
> em-tramp
> ~/.emacs.d [1] $ eshell/sudo touch /usr/local/bin/test-file
> ~/.emacs.d $ eshell/sudo rm /usr/local/bin/test-file
> Removing old name: Permission denied, /usr/local/bin/test-file

This is the correct behavior; you shouldn't be able to delete the file 
using this method. In short, "/usr/local/bin/test-file" refers to a 
*local* file name, so it's not going through Tramp's "sudo" method, and 
thus it's correct to report that you don't have permission.

Some more detail: Eshell built-in commands like "rm" (which the built-in 
"eshell/sudo" will call) treat absolute file names as ordinary, local 
files, just like the rest of Emacs would. Specifically, it won't 
automatically prepend the "/sudo::" method to it. Doing that is 
bug#70792, which I have a patch for but haven't finished yet.