all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Lars Ingebrigtsen <larsi@gnus.org>
To: Michael Albinus <michael.albinus@gmx.de>
Cc: 44217@debbugs.gnu.org, Jean Louis <bugs@gnu.support>
Subject: bug#44217: bug#44216: 28.0.50; Incorret during delete in Tramp: Trashing...done
Date: Tue, 27 Oct 2020 08:42:47 +0100	[thread overview]
Message-ID: <87ft60ru6g.fsf@gnus.org> (raw)
In-Reply-To: <878sbtuhj6.fsf@gmx.de> (Michael Albinus's message of "Mon, 26 Oct 2020 16:35:25 +0100")

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





  reply	other threads:[~2020-10-27  7:42 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-10-25 19:38 bug#44217: 28.0.50; Incorret during delete in Tramp: Trashing...done Jean Louis
2020-10-26 11:14 ` bug#44217: bug#44216: " Lars Ingebrigtsen
2020-10-26 11:51   ` Jean Louis
2020-10-26 16:56     ` Michael Albinus
2020-10-26 17:01     ` Eli Zaretskii
2020-10-26 13:11   ` Michael Albinus
2020-10-26 13:17     ` Lars Ingebrigtsen
2020-10-26 15:35       ` Michael Albinus
2020-10-27  7:42         ` Lars Ingebrigtsen [this message]
2020-10-27 15:32           ` Michael Albinus
2020-10-27 17:17             ` Jean Louis
2020-10-27 20:12               ` Michael Albinus
2020-10-28 10:54                 ` Jean Louis
2020-11-01 11:59                   ` Michael Albinus
2020-11-01 12:36                     ` Jean Louis
2020-11-01 13:03                       ` bug#44217: " Michael Albinus
2020-11-01 13:33                         ` Jean Louis
2020-11-01 14:48                           ` Michael Albinus
2020-10-27 17:42             ` bug#44217: (no subject) Lars Ingebrigtsen
2020-10-27 20:20               ` bug#44217: none Michael Albinus
2020-10-28  9:27                 ` Lars Ingebrigtsen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87ft60ru6g.fsf@gnus.org \
    --to=larsi@gnus.org \
    --cc=44217@debbugs.gnu.org \
    --cc=bugs@gnu.support \
    --cc=michael.albinus@gmx.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.