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

Previous Next

Package: emacs;

Reported by: Ruijie Yu <ruijie <at> netyu.xyz>

Date: Sun, 1 Jan 2023 08:36:04 UTC

Severity: normal

Merged with 60460

Found in version 30.0.50

Fixed in version 30.1

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

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: help-debbugs <at> gnu.org (GNU bug Tracking System)
To: Ruijie Yu <ruijie <at> netyu.xyz>
Cc: tracker <at> debbugs.gnu.org
Subject: bug#60460: closed (30.0.50; [FR] avoid putting remote files to
 local trash)
Date: Sun, 01 Jan 2023 20:38:05 +0000
[Message part 1 (text/plain, inline)]
Your message dated Sun, 01 Jan 2023 08:20:18 -0600
with message-id <sdvzgb272l0.fsf <at> fw.net.yu>
and subject line Re: bug#60462: 30.0.50; [FR] avoid putting remote files to local trash
has caused the debbugs.gnu.org bug report #60462,
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.)


-- 
60462: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=60462
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: Ruijie Yu <ruijie <at> netyu.xyz>
To: 60462 <at> debbugs.gnu.org
Cc: 60462-done <at> debbugs.gnu.org
Subject: Re: bug#60462: 30.0.50; [FR] avoid putting remote files to local trash
Date: Sun, 01 Jan 2023 08:20:18 -0600
Sorry about the duplicated bug.  I sent the first email two days ago and
the mail never showed up, so I figured I had forgotten to send it and
sent again.

The bug-tracker doc doesn't say whether the bug-opener (me) can close
the bug, so I'll try to close it via CC.  If I cannot close the bug, can
someone who can close bugs close this?

Closing in favor of bug#60460.

Best,


RY


This bug report was last modified 2 years and 107 days ago.

Previous Next


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