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

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

[Jean Louis]

I have the variable trash-directory set and files go to ~/tmp/Trash

During Tramp ssh://example.com:~/ session I have delete a file and I can
see the message: Trashing...done which should not be during Tramp
session, as it gave me impression that file will be now transferred in
background to my local Trash directory which not the case. Not that I
have seen the file in Trash.


In GNU Emacs 28.0.50 (build 21, x86_64-pc-linux-gnu, X toolkit, cairo version 1.14.8, Xaw3d scroll bars)
 of 2020-10-24 built on protected.rcdrun.com
Repository revision: 10e7c76ee3e263a7691745d9384bae475c2f5c86
Repository branch: master
Windowing system distributor 'The X.Org Foundation', version 11.0.11907000
System Description: Hyperbola GNU/Linux-libre

Configured using:
 'configure --prefix=/package/text/emacs-2020-10-24 --with-modules
 --with-x-toolkit=athena'

Configured features:
XAW3D XPM JPEG TIFF GIF PNG RSVG CAIRO SOUND GPM DBUS GSETTINGS GLIB
NOTIFY INOTIFY ACL GNUTLS LIBXML2 FREETYPE HARFBUZZ M17N_FLT LIBOTF ZLIB
TOOLKIT_SCROLL_BARS LUCID X11 XDBE XIM MODULES THREADS JSON PDUMPER
LCMS2

Important settings:
  value of $LC_ALL: de_DE.UTF-8
  value of $LANG: de_DE.UTF-8
  value of $XMODIFIERS: @im=exwm-xim
  locale-coding-system: utf-8-unix

Major mode: Lisp Interaction

Minor modes in effect:
  tooltip-mode: t
  global-eldoc-mode: t
  eldoc-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t
  transient-mark-mode: t

Load-path shadows:
None found.

Features:
(shadow sort hashcash mail-extr emacsbug message rmc puny dired
dired-loaddefs rfc822 mml easymenu mml-sec epa derived epg epg-config
gnus-util rmail rmail-loaddefs auth-source cl-seq eieio eieio-core
cl-macs eieio-loaddefs password-cache json map text-property-search
time-date subr-x seq byte-opt gv bytecomp byte-compile cconv mm-decode
mm-bodies mm-encode mail-parse rfc2231 mailabbrev gmm-utils mailheader
cl-loaddefs cl-lib sendmail rfc2047 rfc2045 ietf-drums mm-util
mail-prsvr mail-utils tooltip eldoc electric uniquify ediff-hook
vc-hooks lisp-float-type mwheel term/x-win x-win term/common-win x-dnd
tool-bar dnd fontset image regexp-opt fringe tabulated-list replace
newcomment text-mode elisp-mode lisp-mode prog-mode register page
tab-bar menu-bar rfn-eshadow isearch timer select scroll-bar mouse
jit-lock font-lock syntax facemenu font-core term/tty-colors frame
minibuffer cl-generic cham georgian utf-8-lang misc-lang vietnamese
tibetan thai tai-viet lao korean japanese eucjp-ms cp51932 hebrew greek
romanian slovak czech european ethiopic indian cyrillic chinese
composite charscript charprop case-table epa-hook jka-cmpr-hook help
simple abbrev obarray cl-preloaded nadvice button loaddefs faces
cus-face macroexp files window text-properties overlay sha1 md5 base64
format env code-pages mule custom widget hashtable-print-readable
backquote threads dbusbind inotify lcms2 dynamic-setting
system-font-setting font-render-setting cairo x-toolkit x multi-tty
make-network-process emacs)

Memory information:
((conses 16 55755 4779)
 (symbols 48 7130 1)
 (strings 32 19992 2080)
 (string-bytes 1 643851)
 (vectors 16 12572)
 (vector-slots 8 171868 9158)
 (floats 8 26 26)
 (intervals 56 258 0)
 (buffers 992 12))

-- 
Thanks,
Jean Louis

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

[Lars Ingebrigtsen]

Jean Louis <bugs@gnu.support> writes:

> I have the variable trash-directory set and files go to ~/tmp/Trash
>
> During Tramp ssh://example.com:~/ session I have delete a file and I can
> see the message: Trashing...done which should not be during Tramp
> session, as it gave me impression that file will be now transferred in
> background to my local Trash directory which not the case. Not that I
> have seen the file in Trash.

Please try to give more detailed bug reports with recipes starting from
"emacs -Q".

I reproduced this bug by setting:

(setq delete-by-moving-to-trash t
      trash-directory "~/Trash/")

and then going to "/ssh:other-host:/tmp/" and deleting a file.  As you
say, the file isn't moved to ~/Trash.

This is because:

(defun tramp-get-remote-trash (vec)
  "Determine remote `trash' command.
This command is returned only if `delete-by-moving-to-trash' is non-nil."
  (and delete-by-moving-to-trash
       (with-tramp-connection-property vec "trash"
	 (tramp-message vec 5 "Finding a suitable `trash' command")
	 (tramp-find-executable vec "trash" (tramp-get-remote-path vec)))))

Tramp is looking for an executable on the remote host called "trash"?
Which doesn't exist.

Shouldn't Tramp then move the file to `trash-directory' instead of
giving up and just deleting the file?

If this is working as designed, it should at least be mentioned in the
doc string(s) and the manual.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

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

[Jean Louis]

That is great if the Tramp is looking for remote `trash' command, as
there is software `trash-cli' it is named `trash' and it is
compatible with GNU rm. It is convenient.

That feature is not using the specified variable, so it is using
Freedesktop.org specified Trash location, at first invokation it was
~/.local/share/Trash and it may be configured.

In that case, when trash-directory variable is configured that is
separate from remote Trash and from Freedesktop.org and I rather
prefer specifying the trash directory myself.

The description of this variable is vague as I cannot know is it in
the context of Freedesktop.org "system's  trash", as now the remote
`trash' command is actually using such, though users could have remote
trash command to use anything; or is it in the context of being
configured through Emacs

Hide Delete By Moving To Trash: Toggle  on (non-nil)
    State : SAVED and set.
   Specifies whether to use the system’s trash can. Hide
   When non-nil, certain file deletion commands use the function
   ‘move-file-to-trash’ instead of deleting files outright.
   This includes interactive calls to ‘delete-file’ and
   ‘delete-directory’ and the Dired deletion commands.
Groups: Auto Save

As then  this settings clarify the first description.

Hide Trash Directory: Value Menu Directory: /home/data1/protected/tmp/Trash/
    State : SAVED and set.
   Directory for ‘move-file-to-trash’ to move files and directories to. More
Groups: Auto Save

In my opinion "system's trash" should be clarified. So far I
understand how it is now, it is Emacs's system's trash, it is not OS
system's trash as variable is set via Emacs.


* Lars Ingebrigtsen <larsi@gnus.org> [2020-10-26 14:15]:
> Jean Louis <bugs@gnu.support> writes:
> 
> > I have the variable trash-directory set and files go to ~/tmp/Trash
> >
> > During Tramp ssh://example.com:~/ session I have delete a file and I can
> > see the message: Trashing...done which should not be during Tramp
> > session, as it gave me impression that file will be now transferred in
> > background to my local Trash directory which not the case. Not that I
> > have seen the file in Trash.
> 
> Please try to give more detailed bug reports with recipes starting from
> "emacs -Q".
> 
> I reproduced this bug by setting:
> 
> (setq delete-by-moving-to-trash t
>       trash-directory "~/Trash/")
> 
> and then going to "/ssh:other-host:/tmp/" and deleting a file.  As you
> say, the file isn't moved to ~/Trash.
> 
> This is because:
> 
> (defun tramp-get-remote-trash (vec)
>   "Determine remote `trash' command.
> This command is returned only if `delete-by-moving-to-trash' is non-nil."
>   (and delete-by-moving-to-trash
>        (with-tramp-connection-property vec "trash"
> 	 (tramp-message vec 5 "Finding a suitable `trash' command")
> 	 (tramp-find-executable vec "trash" (tramp-get-remote-path vec)))))
> 
> Tramp is looking for an executable on the remote host called "trash"?
> Which doesn't exist.
> 
> Shouldn't Tramp then move the file to `trash-directory' instead of
> giving up and just deleting the file?
> 
> If this is working as designed, it should at least be mentioned in the
> doc string(s) and the manual.


-- 
Jean Louis

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

[Michael Albinus]

Jean Louis <bugs@gnu.support> writes:

Hi Jean,

> Hide Trash Directory: Value Menu Directory: /home/data1/protected/tmp/Trash/
>     State : SAVED and set.
>    Directory for ‘move-file-to-trash’ to move files and directories to. More
> Groups: Auto Save
>
> In my opinion "system's trash" should be clarified. So far I
> understand how it is now, it is Emacs's system's trash, it is not OS
> system's trash as variable is set via Emacs.

As discussed the other messages with Lars, trash-directory shell tell
that it is responsible for local files and directories only.

Best regards, Michael.

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

[Eli Zaretskii]

> Date: Mon, 26 Oct 2020 14:51:48 +0300
> From: Jean Louis <bugs@gnu.support>
> Cc: Michael Albinus <michael.albinus@gmx.de>, 44217@debbugs.gnu.org
> 
> Hide Trash Directory: Value Menu Directory: /home/data1/protected/tmp/Trash/
>     State : SAVED and set.
>    Directory for ‘move-file-to-trash’ to move files and directories to. More
> Groups: Auto Save
> 
> In my opinion "system's trash" should be clarified. So far I
> understand how it is now, it is Emacs's system's trash, it is not OS
> system's trash as variable is set via Emacs.

The doc string says:

  Relative paths are interpreted relative to ‘default-directory’.
  If the value is nil, Emacs uses a freedesktop.org-style trashcan.

Which part of this is unclear?

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

[Michael Albinus]

Lars Ingebrigtsen <larsi@gnus.org> writes:

Hi Lars,

>> I have the variable trash-directory set and files go to ~/tmp/Trash
>>
>> During Tramp ssh://example.com:~/ session I have delete a file and I can
>> see the message: Trashing...done which should not be during Tramp
>> session, as it gave me impression that file will be now transferred in
>> background to my local Trash directory which not the case. Not that I
>> have seen the file in Trash.

The message "Trashing...done" comes from dired, just because of the
rguments it calls delete-file with. This has nothing to do with what
Tramp does.

> Please try to give more detailed bug reports with recipes starting from
> "emacs -Q".
>
> I reproduced this bug by setting:
>
> (setq delete-by-moving-to-trash t
>       trash-directory "~/Trash/")
>
> and then going to "/ssh:other-host:/tmp/" and deleting a file.  As you
> say, the file isn't moved to ~/Trash.

How did you delete the file? You must give the optional argument TRASH a
non-nil value, as in

(delete-file "/ssh:other-host:/tmp/file" t)

> This is because:
>
> (defun tramp-get-remote-trash (vec)
>   "Determine remote `trash' command.
> This command is returned only if `delete-by-moving-to-trash' is non-nil."
>   (and delete-by-moving-to-trash
>        (with-tramp-connection-property vec "trash"
> 	 (tramp-message vec 5 "Finding a suitable `trash' command")
> 	 (tramp-find-executable vec "trash" (tramp-get-remote-path vec)))))
>
> Tramp is looking for an executable on the remote host called "trash"?
> Which doesn't exist.

Yep. Btw, the "trash" command is part of the trash-cli package, which
exists for example for Ubuntu and Fedora.

> 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. And it would be a security flaw, if remote files would be moved
to the local "~/Trash" directory.

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

Best regards, Michael.

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

[Lars Ingebrigtsen]

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

> How did you delete the file? You must give the optional argument TRASH a
> non-nil value, as in
>
> (delete-file "/ssh:other-host:/tmp/file" t)

In dired, which basically does that.

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

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

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

---

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.



-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

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.

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

[Lars Ingebrigtsen]

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

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

I don't see the difference (except as a matter of practicality; that it
would be slow).  If you've NFS-mounted (or SMB or whatever) a file
system, and you delete it in Emacs, Emacs will move it to the trash can
you've specified (if you've specified that Emacs should do so).

But remote files accessed via Tramp don't do this, and that's unexpected
(as demonstrated by this bug report).

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

I've never seen such a system -- any OS I've used that has had a trash
can has had only one trash can (per user), as far as I can recall.

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

So if you know something that's not documented about move-file-to-trash,
then you can indirectly interpret this correctly?  That's a roundabout
way of saying "indeed, this isn't documented at all".  :-/

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

I'm not sure what you mean by "it shall make it clear".  Do you mean "it
should make it clear", or that you're going to fix the doc strings here?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

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

[Michael Albinus]

Lars Ingebrigtsen <larsi@gnus.org> writes:

Hi Lars,

>> 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.
>
> I don't see the difference (except as a matter of practicality; that it
> would be slow).  If you've NFS-mounted (or SMB or whatever) a file
> system, and you delete it in Emacs, Emacs will move it to the trash can
> you've specified (if you've specified that Emacs should do so).
>
> But remote files accessed via Tramp don't do this, and that's unexpected
> (as demonstrated by this bug report).

That's true.

>> 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").
>
> I've never seen such a system -- any OS I've used that has had a trash
> can has had only one trash can (per user), as far as I can recall.

The Trash specification
<https://specifications.freedesktop.org/trash-spec/trashspec-latest.html>
says

The “home trash” SHOULD function as the user's main trash directory. [...]
An implementation [...] MAY also choose to provide trashing in the “top
directories” of some or all mounted resources.

>>> 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.
>
> So if you know something that's not documented about move-file-to-trash,
> then you can indirectly interpret this correctly?  That's a roundabout
> way of saying "indeed, this isn't documented at all".  :-/

I stand corrected, move-file-to-trash works also for remote
files. However, the result might be surprising. I've created a test file
on a remote machine, "/ssh:ford:/tmp/aaa". Then I have called
move-file-to-trash over this file. As expected, the file is removed on
the remote machine, and it appears as "~/.local/share/Trash/files/aaa".
However, in "~/.local/share/Trash/info/aaa.trashinfo" there is

Path=/ssh%3aford%3a/tmp/aaa

This will be unexpected, at least for tools which try to restore trashed
files.

However, perhaps Tramp shall call move-file-to-trash when deleting
remote files, argument TRASH and variable delete-by-moving-to-trash are
non-nil? Instead of calling the remote trash command?

Best regards, Michael.

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

[Jean Louis]

* Michael Albinus <michael.albinus@gmx.de> [2020-10-27 18:33]:
> The Trash specification
> <https://specifications.freedesktop.org/trash-spec/trashspec-latest.html>
> says

Not universal for every OSs. Freedesktop specification is exclusively
for GNU/Linux which accept parts or whole of Freedesktop, yet there
are those which do not.

Emacs should not be exclusively for GNU/Linux. It is used on plethora
of *BSD derivatives, on UNIX, then on OS X, etc. So not each is
supporting that. There wil be new fully free OS HyperbolaBSD that may
not support Freedesktop but will support many GNU programs.

-- 
Jean Louis

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

[Michael Albinus]

Jean Louis <bugs@gnu.support> writes:

Hi Jean,

>> The Trash specification
>> <https://specifications.freedesktop.org/trash-spec/trashspec-latest.html>
>> says
>
> Not universal for every OSs. Freedesktop specification is exclusively
> for GNU/Linux which accept parts or whole of Freedesktop, yet there
> are those which do not.

GNU/Linux is the primary target for Emacs. It is perfect to support its spec.

> Emacs should not be exclusively for GNU/Linux. It is used on plethora
> of *BSD derivatives, on UNIX, then on OS X, etc. So not each is
> supporting that. There wil be new fully free OS HyperbolaBSD that may
> not support Freedesktop but will support many GNU programs.

Emacs is not exclusively for GNU/Linux, but it regards it as its home.
If the function system-move-file-to-trash is defined, it is called
inside move-file-to-trash. For w32 systems, this function is
defined. *BSD or macOS or whatever platform could define an own
system-move-file-to-trash as well.

Best regards, Michael.

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

[Jean Louis]

* Michael Albinus <michael.albinus@gmx.de> [2020-10-27 23:13]:
> Jean Louis <bugs@gnu.support> writes:
> 
> Hi Jean,
> 
> >> The Trash specification
> >> <https://specifications.freedesktop.org/trash-spec/trashspec-latest.html>
> >> says
> >
> > Not universal for every OSs. Freedesktop specification is exclusively
> > for GNU/Linux which accept parts or whole of Freedesktop, yet there
> > are those which do not.
> 
> GNU/Linux is the primary target for Emacs. It is perfect to support its spec.

Freedesktop.org is not equivalent to GNU/Linux.

It is maybe popular but it is not and need not be standard.

From: https://www.freedesktop.org/wiki/Specifications/

Interoperability specifications

freedesktop.org produces specifications for interoperability, but we
are not an official standards body. There is no requirement for
projects to implement all of these specifications, nor certification.

so

GNU/Linux distributions may decide to adhere or may not.

I hope you that Emacs should NOT be exclusively target for GNU/Linux
distributions adopting some of specifications from Freedesktop.org as
Emacs is widely used for example on BSD systems. 

Tramp is supporting various file systems and those file systems are
not necessarily on GNU/Linux and thus I do not think it is necessary
to include that support for Tramp considering wild range of file
systems that can be accessed and those file system yet to come.

Tramp should not target Freedesktop.org specification on remote file
systems when variable `delete-by-moving-to-trash' is set, this
variable should be local only.

- If it is not set, I see no message from Tramp related to trashing
  when file is being deleted.

- If it is set, then I see that Tramp is trashing the file, although
  it is not trashing the file in this context.

- my remote system does not have any trash nor Freedesktop.org
  specification.

- And I am using LineageOS/Replicant/Android remote file systems

Let us also note that Freedesktop.org is for "desktop" so it is not
specification for servers. Tramp accessing remote SSH or other servers
should not assume automatically it is accessing remote desktops.

Tramp may access remote files by using FTP, rsync, scp, and other
protocols, I just hope that trash inclusion is not intertwined in
those protocols where remote command execution would not even work.

OpenSSH was targeting primarily OpenBSD and we use it wildly in
GNU/Linux, it would be somehow unfair to say that Emacs with the Tramp
which is using OpenSSH coming from OpenBSD is targeting only
GNU/Linux. Emacs is widely used on all *BSD derivates and other OSes
not being GNU/Linux. 

Documentation:
Specifies whether to use the system’s trash can.
When non-nil, certain file deletion commands use the function
‘move-file-to-trash’ instead of deleting files outright.
This includes interactive calls to ‘delete-file’ and
‘delete-directory’ and the Dired deletion commands.

I think that variable shall be local only, so that Tramp does not even
attempt moving anything to Trash remotely.

While that Trash thing would be convenient for me personally, I think
it would be badly designed for above reasons.


-- 
Jean Louis

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

[Michael Albinus]

Jean Louis <bugs@gnu.support> writes:

Hi Jean,

>> > Not universal for every OSs. Freedesktop specification is exclusively
>> > for GNU/Linux which accept parts or whole of Freedesktop, yet there
>> > are those which do not.
>>
>> GNU/Linux is the primary target for Emacs. It is perfect to support its spec.
>
> Freedesktop.org is not equivalent to GNU/Linux.
>
> It is maybe popular but it is not and need not be standard.
>
> From: https://www.freedesktop.org/wiki/Specifications/
>
> Interoperability specifications
>
> freedesktop.org produces specifications for interoperability, but we
> are not an official standards body. There is no requirement for
> projects to implement all of these specifications, nor certification.
>
> so
>
> GNU/Linux distributions may decide to adhere or may not.
>
> I hope you that Emacs should NOT be exclusively target for GNU/Linux
> distributions adopting some of specifications from Freedesktop.org as
> Emacs is widely used for example on BSD systems.

Emacs does not exclusively target for GNU/Linux systems. Every user is
free to set trash-directory to whatever value. For every platform, a
system specific system-move-file-to-trash function can be implemented,
it exists already for w32.

> Tramp may access remote files by using FTP, rsync, scp, and other
> protocols, I just hope that trash inclusion is not intertwined in
> those protocols where remote command execution would not even work.

I've implemented trashing to local trash for whatever connection
protocol (except ftp, because it has its own implementation,
ange-ftp.el). Just pushed to master.

Could you, pls check?

Best regards, Michael.

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

[Jean Louis]

* Michael Albinus <michael.albinus@gmx.de> [2020-11-01 15:00]:
> Emacs does not exclusively target for GNU/Linux systems. Every user is
> free to set trash-directory to whatever value. For every platform, a
> system specific system-move-file-to-trash function can be implemented,
> it exists already for w32.
> 
> > Tramp may access remote files by using FTP, rsync, scp, and other
> > protocols, I just hope that trash inclusion is not intertwined in
> > those protocols where remote command execution would not even work.
> 
> I've implemented trashing to local trash for whatever connection
> protocol (except ftp, because it has its own implementation,
> ange-ftp.el). Just pushed to master.
> 
> Could you, pls check?

Thank you, while I am git pull-ing and compiling, do you mean that you
have implemented that scp or ssh connections would be moving files to
local trash?

Does that mean if I have delete-by-moving-to-trash set for local file
system that in case of deletion of remote files those files would be
transferred to my local computer? That would be counter feature. As
remotely I am keeping huge files. Somehow I was thinking to distinct
between local and remote.

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

[Michael Albinus]

Jean Louis <bugs@gnu.support> writes:

Hi Jean,

> Thank you, while I am git pull-ing and compiling, do you mean that you
> have implemented that scp or ssh connections would be moving files to
> local trash?

Yes.

> Does that mean if I have delete-by-moving-to-trash set for local file
> system that in case of deletion of remote files those files would be
> transferred to my local computer? That would be counter feature. As
> remotely I am keeping huge files. Somehow I was thinking to distinct
> between local and remote.

Do not trash them. Delete them, or move them manually somewhere else.

Best regards, Michael.

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

[Jean Louis]

* Michael Albinus <michael.albinus@gmx.de> [2020-11-01 16:03]:
> Jean Louis <bugs@gnu.support> writes:
> 
> Hi Jean,
> 
> > Thank you, while I am git pull-ing and compiling, do you mean that you
> > have implemented that scp or ssh connections would be moving files to
> > local trash?
> 
> Yes.
> 
> > Does that mean if I have delete-by-moving-to-trash set for local file
> > system that in case of deletion of remote files those files would be
> > transferred to my local computer? That would be counter feature. As
> > remotely I am keeping huge files. Somehow I was thinking to distinct
> > between local and remote.
> 
> Do not trash them. Delete them, or move them manually somewhere
> else.

Thank you, I appreciate your efforts. My testing was just find,
deleted files on remote computers are transferred to local trash when
I have variable delete-by-moving-to-trash defined.

Often I am editing system files remotely and deleting backup~ files
for security reasons. Those files are small and transferred
automatically to local trash for some time, and I find it useful, with
less fear if I make some problem remotely.

For big files like videos and remote DVD images I will have to find
way to turn off trashing when connecting to Tramp. I can make local
directory variables if that works in Tramp too, or make small function
to verify if size of files is like more than 100K and switch off
delete by moving to trash.

Thank you.

Now close.

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

[Michael Albinus]

Jean Louis <bugs@gnu.support> writes:

Hi Jean,

> Thank you, I appreciate your efforts. My testing was just find,
> deleted files on remote computers are transferred to local trash when
> I have variable delete-by-moving-to-trash defined.
>
> Thank you.
>
> Now close.

Thanks for confirmation, I'm closing the bug.

Best regards, Michael.

bug#44217: (no subject)

[Lars Ingebrigtsen]

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

> The Trash specification
> <https://specifications.freedesktop.org/trash-spec/trashspec-latest.html>
> says
>
> The “home trash” SHOULD function as the user's main trash directory. [...]
> An implementation [...] MAY also choose to provide trashing in the “top
> directories” of some or all mounted resources.

Ah, I see.

> However, in "~/.local/share/Trash/info/aaa.trashinfo" there is
>
> Path=/ssh%3aford%3a/tmp/aaa
>
> This will be unexpected, at least for tools which try to restore trashed
> files.

Yes, perhaps the .trashinfo file shouldn't be created in these
instances...

> However, perhaps Tramp shall call move-file-to-trash when deleting
> remote files, argument TRASH and variable delete-by-moving-to-trash are
> non-nil? Instead of calling the remote trash command?

Yes, I think that would make sense.

But if trash-directory is nil, and there is a remote trash command...
perhaps Tramp should call the remote trash command anyway?  (Many
permutations of possibly correct behaviour here.  :-/)

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#44217: none

[Michael Albinus]

Lars Ingebrigtsen <larsi@gnus.org> writes:

>> However, in "~/.local/share/Trash/info/aaa.trashinfo" there is
>>
>> Path=/ssh%3aford%3a/tmp/aaa
>>
>> This will be unexpected, at least for tools which try to restore trashed
>> files.
>
> Yes, perhaps the .trashinfo file shouldn't be created in these
> instances...

It is created according to the XDG spec. We shouldn't fail to do it. And
maybe, Emacs will add an own trash recovery function, which would be
able to handle such remote paths?

>> However, perhaps Tramp shall call move-file-to-trash when deleting
>> remote files, argument TRASH and variable delete-by-moving-to-trash are
>> non-nil? Instead of calling the remote trash command?
>
> Yes, I think that would make sense.
>
> But if trash-directory is nil, and there is a remote trash command...
> perhaps Tramp should call the remote trash command anyway?  (Many
> permutations of possibly correct behaviour here.  :-/)

We must be consistent. A remote trash command will move the file to the
remote trash can. Tramp, using move-file-to-trash, will move the file to
the local trash can. A user couldn't know, whether a trash can for a
remote file will be located locally or remotely. So we shall use either
a remote or a local trash can, and not mixed.

The local trash can can be used always. The remote trash can can be used
only, when the remote system offers the "trash" command. This doesn't
happen by default.

Best regards, Michael.

bug#44217: none

[Lars Ingebrigtsen]

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

>>> Path=/ssh%3aford%3a/tmp/aaa
>>>
>>> This will be unexpected, at least for tools which try to restore trashed
>>> files.
>>
>> Yes, perhaps the .trashinfo file shouldn't be created in these
>> instances...
>
> It is created according to the XDG spec. We shouldn't fail to do it. And
> maybe, Emacs will add an own trash recovery function, which would be
> able to handle such remote paths?

I was mainly worried about confusing other programs that look at
trash -- will they have strange issues when confronted by these Path
entries?  

> We must be consistent. A remote trash command will move the file to the
> remote trash can. Tramp, using move-file-to-trash, will move the file to
> the local trash can. A user couldn't know, whether a trash can for a
> remote file will be located locally or remotely. So we shall use either
> a remote or a local trash can, and not mixed.

Yeah, consistency would be good here, so just using the local trash can
is probably the best option.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no