bug#60460: 30.0.50; [FR] avoid putting remote files to local trash

bug#60460: 30.0.50; [FR] avoid putting remote files to local trash

[Ruijie Yu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

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@localhost:.bashrc" and
"/sshx:user@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

bug#60460: 30.0.50; [FR] avoid putting remote files to local trash

[Drew Adams]

> 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....
> 2. Use a dedicated local trash directory for each remote, optionally
> behind a toggle.  

(Caveat: I'm not knowledgeable about sending
files to trash.)

I would have thought that we already have a way
for users to customize which files and dirs get
sent to trash.

Now I see that option `delete-by-moving-to-trash'
is just a simple nil/t Boolean, as opposed to
being nil (for don't trash) and non-nil for the
possibility of filtering.

Not trashing remote files is just one kind of
filtering.  And you say that you want to do that
in particular because some of your remote files
are large.  Filtering out large files (local or
remote) is another possibility (logically not
the same as filtering out remote files).

Users could have any number of criteria they
want to use, to filter inclusion/exclusion of
files to move to trash.

Why not use a mechanism similar to what we use
with `recentf.el'?  There, we have user option
`recentf-exclude'.  That lets you use multiple
regexps and predicates to specify the files
you want to exclude from inclusion in the list
of recent files.

bug#60460: 30.0.50; [FR] avoid putting remote files to local trash

[Ruijie Yu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Drew Adams <drew.adams@oracle.com> writes:

>> 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....
>> 2. Use a dedicated local trash directory for each remote, optionally
>> behind a toggle.
>
> (Caveat: I'm not knowledgeable about sending
> files to trash.)
>
> I would have thought that we already have a way
> for users to customize which files and dirs get
> sent to trash.
>
> Now I see that option `delete-by-moving-to-trash'
> is just a simple nil/t Boolean, as opposed to
> being nil (for don't trash) and non-nil for the
> possibility of filtering.
>
> Not trashing remote files is just one kind of
> filtering.  And you say that you want to do that
> in particular because some of your remote files
> are large.  Filtering out large files (local or
> remote) is another possibility (logically not
> the same as filtering out remote files).
>
> Users could have any number of criteria they
> want to use, to filter inclusion/exclusion of
> files to move to trash.
>
> Why not use a mechanism similar to what we use
> with `recentf.el'?  There, we have user option
> `recentf-exclude'.  That lets you use multiple
> regexps and predicates to specify the files
> you want to exclude from inclusion in the list
> of recent files.

Yes, that sounds like a good idea as well.  To expand on your idea, here
are my thoughts.

Similar to what we have for "recentf.el" today, we can have two
variables `delete-by-moving-to-trash-include' and
`delete-by-moving-to-trash-exclude', and make
`delete-by-moving-to-trash' a deprecated alias to
`delete-by-moving-to-trash-include'.  In this case, we can have the
following logic:

1. If both variables are nil, disable trashing;

2. If `dbmtt-include' is not a list, issue a warning (because now we
want a list) and enable universal trashing;

3. Handle predicates and regexps in `dbmtt-include' and `dbmtt-exclude'
similar to how these in `recentf-include' and `recentf-exclude' are
handled in "recentf.el".

One concern I have with this approach is the added complexity to file
deletion logic.  That is, whenever a file needs to be deleted with
trashing potential (TRASH is passed in as non-nil for the relevant
functions), the two lists need to be consulted for this file and all
predicates and regexps need to be run against its filename.

Best,


RY

bug#60460: 30.0.50; [FR] avoid putting remote files to local trash

[Drew Adams]

> Similar to what we have for "recentf.el" today, we can have two
> variables `delete-by-moving-to-trash-include' and
> `delete-by-moving-to-trash-exclude',

That's not similar to `recentf'.  There's no reason to 
have options for both include and exclude.  It's enough
to specify what to exclude (that's what `recentf' does).

> and make `delete-by-moving-to-trash' a deprecated alias
> to `delete-by-moving-to-trash-include'. 

I see no need for that.  We can just change the option's
non-nil value (meaning trash something) to be either:

1. A nonempty list of regexps & predicates (like
   `recentf-exclude'), saying what not to trash.
2. Any other non-nil value, meaning exclude nothing,
   i.e., trash everything.

#1 has to be nonempty, as nil means the opposite:
don't move anything to trash.

Alternatively, the option name could be changed, and
a nil (empty-list) value could mean move _everything_
to trash and `t' could mean move nothing to trash.

I don't think it's worth doing that.  I'd suggest
not renaming and just making the change I suggested.
That's backward-compatible: nil still means don't
trash, and non-nil always means trash (something,
maybe everything).

bug#60460: 30.0.50; [FR] avoid putting remote files to local trash

[Jean Louis]

* Ruijie Yu via "Bug reports for GNU Emacs, the Swiss army knife of text editors <bug-gnu-emacs@gnu.org> [2023-01-01 23:39]:
> Similar to what we have for "recentf.el" today, we can have two
> variables `delete-by-moving-to-trash-include' and
> `delete-by-moving-to-trash-exclude', and make
> `delete-by-moving-to-trash' a deprecated alias to
> `delete-by-moving-to-trash-include'.  In this case, we can have the
> following logic:

It is better keeping the variable `delete-by-moving-to-trash' as it
is, and then just add different options:

- If TRUE move all files to trash
- If NIL, don't use trash
- If 'local-only move only local files to trash
- If FUNCTION filter files by FUNCTION 

I have not seen you closed the other bug, and that this one is active
when I was answering first time, so here I repeat it:

* Ruijie Yu via "Bug reports for GNU Emacs, the Swiss army knife of text editors
<bug-gnu-emacs@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/

bug#60460: 30.0.50; [FR] avoid putting remote files to local trash

[Michael Albinus]

Ruijie Yu via "Bug reports for GNU Emacs, the Swiss army knife of text
editors" <bug-gnu-emacs@gnu.org> writes:

> Hello,

Hi,

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

We could use connection-local variables for achieving this effect. Just
set `delete-by-moving-to-trash' to nil by this mechanism.

Alternatively, we could add a new user option
`remote-file-name-inhibit-delete-by-moving-to-trash' (*), which would
force deletion when set to t. We have similar user options already for
other purposes, like `remote-file-name-inhibit-cache',
`remote-file-name-inhibit-locks' and
`remote-file-name-inhibit-auto-save-visited'.

(*): I'm open for another, shorter name.

> Best,
>
> RY

Best regards, Michael.

bug#60460: 30.0.50; [FR] avoid putting remote files to local trash

[Jean Louis]

* Michael Albinus <michael.albinus@gmx.de> [2023-01-02 12:11]:
> We could use connection-local variables for achieving this effect. Just
> set `delete-by-moving-to-trash' to nil by this mechanism.

I guess the above option is not an option for people using
`delete-by-moving-to-trash'.

> Alternatively, we could add a new user option
> `remote-file-name-inhibit-delete-by-moving-to-trash' (*),

That sounds good.

But what is remote? Is /sudo:: also remote? User may want to have
access to sudo and move those files to Trash as well.

--
Jean

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

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

bug#60460: 30.0.50; [FR] avoid putting remote files to local trash

[Michael Albinus]

Jean Louis <bugs@gnu.support> writes:

Hi Jean,

>> Alternatively, we could add a new user option
>> `remote-file-name-inhibit-delete-by-moving-to-trash' (*),
>
> That sounds good.
>
> But what is remote? Is /sudo:: also remote? User may want to have
> access to sudo and move those files to Trash as well.

"/sudo::" is also remote. And yes, it shouldn't go either to the user's
trash directory (if configured so), it could be a security problem.

> Jean

Best regards, Michael.

bug#60460: 30.0.50; [FR] avoid putting remote files to local trash

[Jean Louis]

* Michael Albinus <michael.albinus@gmx.de> [2023-01-02 13:48]:
> Jean Louis <bugs@gnu.support> writes:
> 
> Hi Jean,
> 
> >> Alternatively, we could add a new user option
> >> `remote-file-name-inhibit-delete-by-moving-to-trash' (*),
> >
> > That sounds good.
> >
> > But what is remote? Is /sudo:: also remote? User may want to have
> > access to sudo and move those files to Trash as well.
> 
> "/sudo::" is also remote. And yes, it shouldn't go either to the user's
> trash directory (if configured so), it could be a security problem.

Beyond this discussion, I don't see security problem. When somebody
has sudo rights, then that person can transfer files anywhere that
person wants.

Settings in Emacs to delete by moving trash are explicit decisions of
user. Same with `sudo'. Administrator gives privilege to `sudoer',
and that sudoer may do what he thinks is right and good.

I would personally prefer that sudo editing goes in trash.

Anyway, when editing with sudo I see this file:

  lrwxrwxrwx   1 root root       46 Jan  2 19:27 .#at.deny -> admin@protected.1904257840789327597

which is dangling symlink, do you know about it? Is it bug?

-- 
Jean

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

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

bug#60460: 30.0.50; [FR] avoid putting remote files to local trash

[Michael Albinus]

Jean Louis <bugs@gnu.support> writes:

Hi Jean,

>> >> Alternatively, we could add a new user option
>> >> `remote-file-name-inhibit-delete-by-moving-to-trash' (*),
>> >
>> > That sounds good.
>> >
>> > But what is remote? Is /sudo:: also remote? User may want to have
>> > access to sudo and move those files to Trash as well.
>>
>> "/sudo::" is also remote. And yes, it shouldn't go either to the user's
>> trash directory (if configured so), it could be a security problem.
>
> Beyond this discussion, I don't see security problem. When somebody
> has sudo rights, then that person can transfer files anywhere that
> person wants.

But there are other attack vectors then. Trash files from root user,
located in the user's home directory, could have weak permissions.

> Settings in Emacs to delete by moving trash are explicit decisions of
> user. Same with `sudo'. Administrator gives privilege to `sudoer',
> and that sudoer may do what he thinks is right and good.
>
> I would personally prefer that sudo editing goes in trash.

You are free to configure respective connection-local variables.

> Anyway, when editing with sudo I see this file:
>
>   lrwxrwxrwx   1 root root       46 Jan  2 19:27 .#at.deny -> admin@protected.1904257840789327597
>
> which is dangling symlink, do you know about it? Is it bug?

No, it is a lock file. See (info "(elisp) File Locks")

Best regards, Michael.

bug#60460: 30.0.50; [FR] avoid putting remote files to local trash

[Jean Louis]

* Michael Albinus <michael.albinus@gmx.de> [2023-01-02 21:31]:
> But there are other attack vectors then. Trash files from root user,
> located in the user's home directory, could have weak permissions.

Those are decisions of administrator and user. Permissions they put on
files is their decision and freedom. 

Any file owned by root and moved to user's home directory somewhere in
the Trash, will have how I tested it, same permission as in root
accessible directories. Let us say /etc or /usr and so on, those files
are anyway either visible by users or some of them in /etc protected
by permissions. Those are system decisions.

Who has sudo rights is system administrator, not necessarily main, but
then those people made decisions.

And moving into trash is useful, especially in case of files in /etc 

Let administrators decide what they want. 

Emacs is high level interface, not low level. On high level there is
almost nothing to be decided what people decided on low level.

For me is not logical to try to prevent people what they want.

Give them option, but don't try preventing them on that high level to
do this or that, what they otherwise can do in their system by using
different file manager.

If I can run other file manager with sudo and move to Trash anywhere
it is specified, then let it be for Emacs users too, as by trying to
"secure" something what otherwise was decided on low level, makes no
sense.

We can't say later "Emacs is more secure as file manager because it
does not allow you to move files managed with sudo to Trash" --
because it is not "more secure" as it is high level, not low level.

> > Settings in Emacs to delete by moving trash are explicit decisions of
> > user. Same with `sudo'. Administrator gives privilege to `sudoer',
> > and that sudoer may do what he thinks is right and good.
> >
> > I would personally prefer that sudo editing goes in trash.
> 
> You are free to configure respective connection-local variables.

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.

> > Anyway, when editing with sudo I see this file:
> >
> >   lrwxrwxrwx   1 root root       46 Jan  2 19:27 .#at.deny -> admin@protected.1904257840789327597
> >
> > which is dangling symlink, do you know about it? Is it bug?
> 
> No, it is a lock file. See (info "(elisp) File Locks")

Alright.

-- 
Jean

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

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

bug#60460: 30.0.50; [FR] avoid putting remote files to local trash

[Michael Albinus]

Jean Louis <bugs@gnu.support> writes:

Hi Jean,

> Those are decisions of administrator and user. Permissions they put on
> files is their decision and freedom.
>
> Any file owned by root and moved to user's home directory somewhere in
> the Trash, will have how I tested it, same permission as in root
> accessible directories. Let us say /etc or /usr and so on, those files
> are anyway either visible by users or some of them in /etc protected
> by permissions. Those are system decisions.
>
> Who has sudo rights is system administrator, not necessarily main, but
> then those people made decisions.
>
> And moving into trash is useful, especially in case of files in /etc
>
> Let administrators decide what they want.
>
> Emacs is high level interface, not low level. On high level there is
> almost nothing to be decided what people decided on low level.
>
> For me is not logical to try to prevent people what they want.
>
> Give them option, but don't try preventing them on that high level to
> do this or that, what they otherwise can do in their system by using
> different file manager.
>
> If I can run other file manager with sudo and move to Trash anywhere
> it is specified, then let it be for Emacs users too, as by trying to
> "secure" something what otherwise was decided on low level, makes no
> sense.
>
> We can't say later "Emacs is more secure as file manager because it
> does not allow you to move files managed with sudo to Trash" --
> because it is not "more secure" as it is high level, not low level.

All true, but there are individual decisions by users. I don't see why
we shall add a special case for sudo (and su, doas, sudoedit, sg, ...) -
all of them identify remote (possibly root owned) files and shall be
handled as such. And then, there are also multi-hop remote file names,
which would need another handling then for sudo and friends.

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

Best regards, Michael.

bug#60460: 30.0.50; [FR] avoid putting remote files to local trash

[Jean Louis]

* Michael Albinus <michael.albinus@gmx.de> [2023-01-03 11:48]:
> All true, but there are individual decisions by users. I don't see why
> we shall add a special case for sudo (and su, doas, sudoedit, sg,
> ...) -

I told that the part of discussion is beyond the bug case. I would not
do that and demand from you to add special cases, when there is
already way offered for that, function `system-move-file-to-trash' is
defined by system user, and solves any issues.

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

Yes, very nice.

-- 
Jean

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

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

bug#60460: 30.0.50; [FR] avoid putting remote files to local trash

[Ruijie Yu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Hi Michael and Jean,

Sorry for the radio silence since my first few messages in this thread
-- life decided to become busy.  Anyways, here below (inline) are some
of my thoughts.

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

> Jean Louis <bugs@gnu.support> writes:
>
> Hi Jean,
>
>> [...]
>>
>> If I can run other file manager with sudo and move to Trash anywhere
>> it is specified, then let it be for Emacs users too, as by trying to
>> "secure" something what otherwise was decided on low level, makes no
>> sense.
>>
>> We can't say later "Emacs is more secure as file manager because it
>> does not allow you to move files managed with sudo to Trash" --
>> because it is not "more secure" as it is high level, not low level.
>
> All true, but there are individual decisions by users. I don't see why
> we shall add a special case for sudo (and su, doas, sudoedit, sg, ...) -
> all of them identify remote (possibly root owned) files and shall be
> handled as such. And then, there are also multi-hop remote file names,
> which would need another handling then for sudo and friends.

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.

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

> Best regards, Michael.

Best,


RY

bug#60460: 30.0.50; [FR] avoid putting remote files to local trash

[Michael Albinus]

Ruijie Yu <ruijie@netyu.xyz> 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.

bug#60460: 30.0.50; [FR] avoid putting remote files to local trash

[Jean Louis]

* Michael Albinus <michael.albinus@gmx.de> [2023-01-07 15:51]:
> > 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'.

Eli said that is not for users to define, as those functions are
defined by developers on Mac OS or Windows, and are not the way for
users to customize their Emacs.

-- 
Jean

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

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

bug#60460: 30.0.50; [FR] avoid putting remote files to local trash

[Michael Albinus]

Jean Louis <bugs@gnu.support> writes:

Hi Jean,

> * Michael Albinus <michael.albinus@gmx.de> [2023-01-07 15:51]:
>> > 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'.
>
> Eli said that is not for users to define, as those functions are
> defined by developers on Mac OS or Windows, and are not the way for
> users to customize their Emacs.

Right, it is not the recommended way (and the Tramp doc doesn't mention
it). The recommended way for remote files are connection-local variables.

Best regards, Michael.

bug#60460: 30.0.50; [FR] avoid putting remote files to local trash

[Michael Albinus]

Michael Albinus <michael.albinus@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.

Best regards, Michael.

bug#60460: 30.0.50; [FR] avoid putting remote files to local trash

[Michael Albinus]

Version: 30.1

Michael Albinus <michael.albinus@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.

bug#60462: 30.0.50; [FR] avoid putting remote files to local trash

[Ruijie Yu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

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

bug#60462: 30.0.50; [FR] avoid putting remote files to local trash

[Ruijie Yu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

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@localhost:.bashrc" and
"/sshx:user@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

bug#60460: 30.0.50; [FR] avoid putting remote files to local trash

[Michael Albinus]

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.