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

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 60462 in the body.
You can then email your comments to 60462 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

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 15:46:33 -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 #10 received at 60462 <at> debbugs.gnu.org (full text, mbox):

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

Message #23 received at 60462 <at> debbugs.gnu.org (full text, mbox):

From: Jean Louis <bugs <at> gnu.support>
To: Ruijie Yu <ruijie <at> netyu.xyz>
Cc: 60462 <at> debbugs.gnu.org
Subject: Re: bug#60462: 30.0.50; [FR] avoid putting remote files to local trash
Date: Mon, 2 Jan 2023 06:34:19 +0300

* Ruijie Yu via "Bug reports for GNU Emacs, the Swiss army knife of text editors <bug-gnu-emacs <at> gnu.org> [2023-01-01 11:37]:
> 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.

Which does not make sense, and which should be user option. 

Look at this bug report:
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=56511

Where Lars said:

> As the doc string of move-file-to-trash says:

> If the function `system-move-file-to-trash' is defined, call it
>  with FILENAME as an argument.

> So just define a function that checks whether FILENAME is a Tramp
> file name or not, and delete the file if it is, but trash otherwise.

IMHO, in my opinion there will be always more users that know how to
use M-x customize, but not know how to define functions. 

I don't think that decision to delete remote files to trash is user
friendly in the first place, and that people using M-x customize are
supposed to even understand "only when the function
`system-move-file-to-trash' is not defined". Defined by who? What
would that mean for somebody who is not Emacs Lisp programmer?!
Probably nothing. User remains helpless here.

Hide Trash Directory: Choice: Value Menu Directory: /home/data1/protected/tmp/Wastebasket/
    State : SAVED and set.
   Directory for ‘move-file-to-trash’ to move files and directories to. Hide
   This directory is used only when the function ‘system-move-file-to-trash’
   is not defined.
   Relative paths are interpreted relative to ‘default-directory’.
   If the value is nil, Emacs uses a freedesktop.org-style trashcan.

I have define my `system-move-file-to-trash' as following, so the
problem is solved individually.

(defun system-move-file-to-trash (filename)
  "Delete only local files. 

This is custom local function as recommended by
`move-file-to-trash'."
  (cond ((file-remote-p filename)
	 (delete-file filename))
	((and trash-directory
	      (not (string-prefix-p 
		    (directory-file-name 
		    (file-name-nondirectory
		     (expand-file-name filename)))
		    trash-directory)))
	 (make-directory (file-name-as-directory trash-directory) t)
	 (rename-file filename (file-name-as-directory trash-directory) t))
	(t (when (y-or-n-p (format "Delete `%s'? "))
	     (delete-file filename)))))

However, as you have found out, and I have found out, this problem is
likely to be discovered over and over again by new Tramp users who
wish to use Wastebasket.

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

That is how I work as well.

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

Good ideas, I wish it could be adopted to become user friendly, one
mouse click and customization and user can be sure that remote files
will not be moved to local Trash.

However we have to think that some users may be using only remote
files and that Trash could eventually be remote as well, right?

--
Jean

Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns

In support of Richard M. Stallman
https://stallmansupport.org/

Message #28 received at 60462 <at> debbugs.gnu.org (full text, mbox):

From: Michael Albinus <michael.albinus <at> gmx.de>
To: Ruijie Yu <ruijie <at> netyu.xyz>
Cc: 60462 <at> debbugs.gnu.org, 60460 <at> debbugs.gnu.org
Subject: Re: bug#60460: 30.0.50; [FR] avoid putting remote files to local trash
Date: Mon, 02 Jan 2023 10:16:48 +0100

Hi,

> 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 mailing list is moderated, and since you were unknown to the
tracker, your report(s) were waiting for moderator approval.

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

Yesterday, I've merged both bugs. Closing one bug by you has closed all
merged bugs. I've reopened them.

> Best,
>
> RY

Best regards, Michael.

Previous Next

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