bug#44217: bug#44216: 28.0.50; Incorret during delete in Tramp: Trashing...done

[Michael Albinus]

Lars Ingebrigtsen <larsi@gnus.org> writes:

Hi Lars,

>>> Shouldn't Tramp then move the file to `trash-directory' instead of
>>> giving up and just deleting the file?
>>
>> Why that? `trash-directory' is defined as target for
>> `move_file_to_trash'; it has nothing to do with deleting of remote
>> files.
>
> It doesn't now, but that's only because it's implemented that way.

When the feature "move to trash" was designed, Tramp was not regarded as
game player. I've tried to implement where it is possible, that is for
ssh-like connections using the remote "trash" command, and for remote
connections based on GVFS using the "gio trash" command. And that's
it. For all other remote connections, we delete the file.

>> And it would be a security flaw, if remote files would be moved
>> to the local "~/Trash" directory.
>
> Well...  no, not more than usual.  You can delete a non-Tramp file from
> an encrypted file system, and have the Trash on a non-encrypted file
> system, and that would be the same flaw.  Whether Tramp is involved or
> not is orthogonal.  (Except as an efficiency thing.)

No, for Tramp it is different. You move the file from one machine to
another. And you change the ownership: one file accessible only by root
on one system, is then accessible by whomever on another machine, in the
waste basket. That is a much more serious security flaw, and it would be
unexpected for the majority of the users.

For that reason, it is common practice to provide one waste basket on
every physical file system, even for different file systems accessible
on the same machine (aka "mounted").

>>> If this is working as designed, it should at least be mentioned in the
>>> doc string(s) and the manual.
>>
>> I believe it is mentioned. See the docstrings of `trash-directory' and
>> `move-file-to-trash'. Well, the latter might explicitly state that it is
>> not intended for remote files, but this is another game.
>
> Neither doc string says anything about remote files?
>
> ---
>
> Directory for ‘move-file-to-trash’ to move files and directories to.
> 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.

It says it indirectly, because move-file-to-trash is intended for local
operation only.

> ---
>
> Move the file (or directory) named FILENAME to the trash.
> When ‘delete-by-moving-to-trash’ is non-nil, this function is
> called by ‘delete-file’ and ‘delete-directory’ instead of
> deleting files outright.
>
> If the function ‘system-move-file-to-trash’ is defined, call it
>  with FILENAME as an argument.
> Otherwise, if ‘trash-directory’ is non-nil, move FILENAME to that
>  directory.
> Otherwise, trash FILENAME using the freedesktop.org conventions,
>  like the GNOME, KDE and XFCE desktop environments.  Emacs moves
>  files only to "home trash", ignoring per-volume trashcans.

As I said the other message, it shall make it clear that it is an
operation for a local file system. As designed. That's why it is called
in delete-file end delete-directory only after the file name handler.

Best regards, Michael.