GNU bug report logs - #60460
30.0.50; [FR] avoid putting remote files to local trash

Previous Next

Full log

View this message in rfc822 format

From: help-debbugs <at> gnu.org (GNU bug Tracking System)
To: Michael Albinus <michael.albinus <at> gmx.de>
Cc: tracker <at> debbugs.gnu.org
Subject: bug#60460: closed (30.0.50; [FR] avoid putting remote files to
 local trash)
Date: Thu, 02 Feb 2023 08:57:02 +0000

[Message part 1 (text/plain, inline)]

Your message dated Thu, 02 Feb 2023 09:56:15 +0100
with message-id <875ycke98w.fsf <at> gmx.de>
and subject line Re: bug#60460: 30.0.50; [FR] avoid putting remote files to local trash
has caused the debbugs.gnu.org bug report #60460,
regarding 30.0.50; [FR] avoid putting remote files to local trash
to be marked as done.

(If you believe you have received this mail in error, please contact
help-debbugs <at> gnu.org.)


-- 
60460: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=60460
GNU Bug Tracking System
Contact help-debbugs <at> gnu.org with problems

[Message part 2 (message/rfc822, inline)]

From: Ruijie Yu <ruijie <at> netyu.xyz>
To: bug-gnu-emacs <at> gnu.org
Subject: 30.0.50; [FR] avoid putting remote files to local trash
Date: Sat, 31 Dec 2022 10:34:16 -0600

Hello,

I have been organizing my files lately over multiple devices using
tramp.  One issue I find with my current setup is that since I set
`delete-by-moving-to-trash' to t, all files, even the remote ones, are
moved to my trash directory.

This, unfortunately, harms my workflow because the files I wanted to
delete include some random multi-gig files, as well as many .git
directories, both of which greatly bottleneck my file-deletion process.
I also don't want to disable trashing globally, because I think putting
local files to trash (which do not introduce a significant delay) is
still a good idea.

In response to this, I want to propose a change to the logic under which
trashing is performed rather than deletion.  However, I am not sure
which one of my following two ideas is more appropriate.

1. Allow the user to disable "moving to local trash" only for remote
files.  I imagine this would entail allowing the user to set
`delete-by-moving-to-trash' to 'local, and modifying `delete-file',
`delete-directory', `dired-internal-do-deletions' among other functions
accordingly.  Alternatively we can have a dedicated variable for this
purpose.

In this case, if `delete-by-moving-to-trash' is set to 'local, whenever
a user deletes a remote file such as "/sudo::/etc/os-release", it is
simply deleted as if via "/sudo:://bin/rm", whereas when the user
deletes a local file ".bashrc", it is moved to trash as normal.

2. Use a dedicated local trash directory for each remote, optionally
behind a toggle.  E.g. for files under "/sudo::" remote, we might have
the trash directory as "/sudo::.local/share/Trash".  I am not sure how
this would interact with `trash-directory', as I have this as nil and
simply let Emacs use the XDG path for trash.

This might additionally pose some challanges when multiple remotes are
aliases to each other, for example, "/sshx:user <at> localhost:.bashrc" and
"/sshx:user <at> 127.0.0.1:.bashrc" logically are the same file, but it might
be hard to programmatically check that two hosts are equivalent.

Best,


RY

[Message part 3 (message/rfc822, inline)]

From: Michael Albinus <michael.albinus <at> gmx.de>
To: Jean Louis <bugs <at> gnu.support>
Cc: ruijie <at> netyu.xyz, 60460-done <at> debbugs.gnu.org
Subject: Re: bug#60460: 30.0.50; [FR] avoid putting remote files to local trash
Date: Thu, 02 Feb 2023 09:56:15 +0100

Version: 30.1

Michael Albinus <michael.albinus <at> gmx.de> writes:

Hi,

>> `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.
>
> FTR, I've added this user option to Emacs master.

No further comment, so I'm closing this bug.

Best regards, Michael.

Previous Next

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