unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Michael Albinus <michael.albinus@gmx.de>
To: Ruijie Yu <ruijie@netyu.xyz>
Cc: Jean Louis <bugs@gnu.support>, 60460@debbugs.gnu.org
Subject: bug#60460: 30.0.50; [FR] avoid putting remote files to local trash
Date: Sat, 07 Jan 2023 13:48:16 +0100	[thread overview]
Message-ID: <878rie33zj.fsf@gmx.de> (raw)
In-Reply-To: <sdvo7rbj78z.fsf@fw.net.yu> (Ruijie Yu's message of "Fri, 06 Jan 2023 21:53:35 -0600")

Ruijie Yu <ruijie@netyu.xyz> writes:

> Hi Michael and Jean,

Hi,

> Considering the security implications of moving remote files into user
> trash, does it make sense if we modify the `move-file-to-trash' function
> such that when a remote file is to be trashed, it is trashed into the
> trash location *of the same remote*?
>
> That is, if we want to trash "/sudo::/etc/sudoers.d/foo" using the
> modified `move-file-to-trash', we can move "/sudo::/etc/sudoers.d/foo"
> into somewhere under "/sudo::.local/share/Trash/".  This way the file
> never leaves the remote, and it does not matter what type the remote is.
> In addition, trashing files from multi-hop remotes would be supported
> natively with the same behavior:
> "/sshx:u1@s1|sshx:u2@s2:.ssh/known_hosts" ->
> "/sshx:u1@s1|sshx:u2@s2:.local/share/Trash/...".
>
> We could lock this proposed change behind a flag to retain backward
> compatibility for those who still prefer to trash remote files by moving
> them into local trash directory.  Regardless, the behavior before and
> after the change for local files should remain the same.

We've used this approach in Emacs 27 (Tramp 2.4), but it wasn't robust
enough. So this was removed from Tramp, knowing that users could define
their own `system-move-file-to-trash'.

>> `remote-file-name-inhibit-delete-by-moving-to-trash' is just an offer as
>> convenience user option, nobody is obliged to use it. There are still
>> connection-local variables or `system-move-file-to-trash' for users with
>> the need of more fine-grained configuration.
>>
>>> Right now I use my function `system-move-file-to-trash' as recommended
>>> by function `move-file-to-trash' and that is great option, I like that
>>> configuration, so I can decide myself what get moved to Trash and what
>>> not, so I will expand it to recognize sudo paths.
>>
>> Sigh.
>
> For my original problem, what I did was to add a hook to `dired-mode' to
> make the offending variable buffer-local, like the following.
>
> (defun cfg-dired-setup ()
>   "Custom setup hook for `dired-mode'."
>   (interactive)
>   ;; other configs omitted
>   (cfg-dired-setup--avoid-remote-trash))
>
> (defun cfg-dired-setup--avoid-remote-trash ()
>   (when (and (boundp 'dired-directory)
>              dired-directory
>              (file-remote-p dired-directory))
>     (setq-local delete-by-moving-to-trash nil)))
>
> (add-hook 'dired-mode-hook #'cfg-dired-setup)
>
> This only fixes my own issue for remote dired buffers, but would not fix
> the trashing issue generally (for example within an eshell session or in
> elisp programatically).

So `remote-file-name-inhibit-delete-by-moving-to-trash' would fit your use case perfectly.

> Best,
>
>
> RY

Best regards, Michael.





  reply	other threads:[~2023-01-07 12:48 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-12-31 16:34 bug#60460: 30.0.50; [FR] avoid putting remote files to local trash Ruijie Yu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-01-01 16:41 ` Drew Adams
2023-01-01 16:47   ` Ruijie Yu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-01-01 18:20     ` Drew Adams
2023-01-02  3:40     ` Jean Louis
2023-01-02  9:09 ` Michael Albinus
2023-01-02 10:35   ` Jean Louis
2023-01-02 10:47     ` Michael Albinus
2023-01-02 16:28       ` Jean Louis
2023-01-02 18:30         ` Michael Albinus
2023-01-02 20:37           ` Jean Louis
2023-01-03  8:47             ` Michael Albinus
2023-01-03 13:53               ` Jean Louis
2023-01-07  3:53               ` Ruijie Yu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-01-07 12:48                 ` Michael Albinus [this message]
2023-01-08  0:37                   ` Jean Louis
2023-01-08  9:20                     ` Michael Albinus
2023-01-08 18:29               ` Michael Albinus
2023-02-02  8:56                 ` Michael Albinus
  -- strict thread matches above, loose matches on Subject: below --
2023-01-01 14:20 bug#60462: " Ruijie Yu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-12-31 21:46 ` Ruijie Yu via Bug reports for GNU Emacs, the Swiss army knife of text editors
     [not found]   ` <handler.60462.D60462.16726054692608.notifdone@debbugs.gnu.org>
2023-01-02  9:16     ` bug#60460: " Michael Albinus

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=878rie33zj.fsf@gmx.de \
    --to=michael.albinus@gmx.de \
    --cc=60460@debbugs.gnu.org \
    --cc=bugs@gnu.support \
    --cc=ruijie@netyu.xyz \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).