From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Michael Albinus Newsgroups: gmane.emacs.bugs Subject: bug#60460: 30.0.50; [FR] avoid putting remote files to local trash Date: Sat, 07 Jan 2023 13:48:16 +0100 Message-ID: <878rie33zj.fsf@gmx.de> References: <87358tfglk.fsf@gmx.de> <87mt71dxhf.fsf@gmx.de> <87ilhoeqlf.fsf@gmx.de> <87bkngdmxd.fsf@gmx.de> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="17279"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: Jean Louis , 60460@debbugs.gnu.org To: Ruijie Yu Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sat Jan 07 13:50:19 2023 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1pE8eQ-0004MU-Um for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 07 Jan 2023 13:50:19 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pE8eC-000468-I1; Sat, 07 Jan 2023 07:50:04 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pE8eA-00045K-Uf for bug-gnu-emacs@gnu.org; Sat, 07 Jan 2023 07:50:03 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1pE8eA-00025W-GU for bug-gnu-emacs@gnu.org; Sat, 07 Jan 2023 07:50:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1pE8eA-0000wr-6q for bug-gnu-emacs@gnu.org; Sat, 07 Jan 2023 07:50:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Michael Albinus Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 07 Jan 2023 12:50:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 60460 X-GNU-PR-Package: emacs Original-Received: via spool by 60460-submit@debbugs.gnu.org id=B60460.16730957423560 (code B ref 60460); Sat, 07 Jan 2023 12:50:02 +0000 Original-Received: (at 60460) by debbugs.gnu.org; 7 Jan 2023 12:49:02 +0000 Original-Received: from localhost ([127.0.0.1]:56671 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pE8dC-0000vB-0n for submit@debbugs.gnu.org; Sat, 07 Jan 2023 07:49:02 -0500 Original-Received: from mout.gmx.net ([212.227.15.19]:33517) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pE8d8-0000uk-U5 for 60460@debbugs.gnu.org; Sat, 07 Jan 2023 07:49:00 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.de; s=s31663417; t=1673095700; bh=gK4VBG+U2Yqhh8jxH7mce8X5UycCWutSW9LVSEwNikk=; h=X-UI-Sender-Class:From:To:Cc:Subject:In-Reply-To:References:Date; b=nLDsRJJp5m2jNkrB93QI4yjnlimvZYNlyBwpgZV3wDY3QjtJkGMQcrF4jZ6tb8POb Us414bn8gwHH/qTax41dCVhONtpLpO5w0yQI8oeAe7e6zLLjcvW+FjJOyg/Xa1Vw16 h5u6r0Rjv68zUWohii1OvsFIx3CFH6gUHm6HKXbhCGYevi3RzTSItGgvVK36xo7hwI wrNVxiZOyCXtDr+IVkkbPV2fx1018W7UgTF08qwCK80kBEgoXURYflpFsgHXMhrzVz 1pnkQvZcCp9HPqF/01VdAJQbu37jwpuLkfQYmX7MYC82H6YjBM5OGATwUpW1PSFeMm mVWMb8QMCN1Rg== X-UI-Sender-Class: 724b4f7f-cbec-4199-ad4e-598c01a50d3a Original-Received: from gandalf.gmx.de ([185.89.37.45]) by mail.gmx.net (mrgmx005 [212.227.17.190]) with ESMTPSA (Nemesis) id 1M3DJv-1pClB83aRB-003ek5; Sat, 07 Jan 2023 13:48:19 +0100 In-Reply-To: (Ruijie Yu's message of "Fri, 06 Jan 2023 21:53:35 -0600") X-Provags-ID: V03:K1:IuinSjBPXTrk2J5wKp57oj8YPfZGqS7SwvSEnwE9BD9gSZqA7iz XClFcp26NeXKPVUHb+ijkjFnM2GfonkwMad2yNAM4qTR5jMvtipjX6S68QtPIx8VobQUuUV QNVX5VOK5x0MqZjcPZor+bQl4NTg0KMhiRNmm6vxawZ3SrKW0QnCJcYXSQ8kOq6wl5HahSL o/mWIbCVTPoubkZCt64mg== UI-OutboundReport: notjunk:1;M01:P0:de2m8fJ8+mo=;oK0ub1svukaooNirMdvg2MbETzl fyoUCQAoIpoO6MtqeyVENlJXzY0LwqJbBJiapLMg69u7eHHgzLF15ZUcMCco5HXHowWAmI4ID tzaMi48HlWVjhNo+uiHEgxv0kvxdG59Oc8+hMqZujMoJljzJn65+oigdmn/3nBEYYGQtSbMAH JI8mqCB4MWoxWoeE3gHQg95oIF6/Kc0xEVKE2LhBPay6PEviPpXeb+FgxthRXOhb0XmRQ4nrP 6Ub+LcsK5l0qYx7XC59yfk0PyKph0gDuJGGYGfqNHRvMUqyDdaTiZB+XRu6olYzeM3L91OwQO dzK6YVJ7kbcNi4c3sYvBiCs25Z72L92CSSPOp0HvOYJSe5Zr05VX06k3kBPYRG8LnpmmoWtEG CaCd+Go6Uy8PFPMhjJbDKr5qkqoJ2wWUAaHllQXpIvvD7dEppj4+m7MDbsQp8zLI68BcrVXfg LuVTQZbHDHOc/NAP9KjOkIR1bY3Y+6sWye0Rgl8eWnFzQoTz6BYAXeszGJcbhE82TiEqJeXrD JPA33CGtukTSEomL9ytHi1yFgQqTei7P4btx6goCil8NLyFzpTm3AOa9sWSsbkTXGNTvokmpr vdCnix7u1ospwxZBkXO6LNoVjXqkxpBzg15wd5+bYGpvC/zTyq6jDz3EyMZFziAvt9IvKe217 UmXe+ukxBFOeogfdqUTUDjChPW4p1GbdlOAv5p0ufqZ4s+xW06Ea7vt3A9ZME3GbxhQJpp+Ui ZLxuGCwrs0uG90TGaLxGXqmDUo+mB/py/DHJPp2Zs0TH63oTcDr8fOLwPy++t+yeeChNGKaZ X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:252796 Archived-At: Ruijie Yu 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.