[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#60462: closed (30.0.50; [FR] avoid putting remote files to local tra

From: GNU bug Tracking System
Subject: bug#60462: closed (30.0.50; [FR] avoid putting remote files to local trash)
Date: Thu, 02 Feb 2023 08:57:02 +0000

Your message dated Thu, 02 Feb 2023 09:56:15 +0100
with message-id <875ycke98w.fsf@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

60460: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=60460
GNU Bug Tracking System
Contact help-debbugs@gnu.org with problems
--- Begin Message --- Subject: 30.0.50; [FR] avoid putting remote files to local trash Date: Sat, 31 Dec 2022 15:46:33 -0600

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

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@localhost:.bashrc" and
"/sshx:user@" logically are the same file, but it might
be hard to programmatically check that two hosts are equivalent.



--- End Message ---
--- Begin Message --- Subject: Re: bug#60460: 30.0.50; [FR] avoid putting remote files to local trash Date: Thu, 02 Feb 2023 09:56:15 +0100 User-agent: Gnus/5.13 (Gnus v5.13)
Version: 30.1

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


>> `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.

--- End Message ---

reply via email to

[Prev in Thread] Current Thread [Next in Thread]