bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Lars Ingebrigtsen
Subject: bug#44217: bug#44216: 28.0.50; Incorret during delete in Tramp: Trashing...done
Date: Tue, 27 Oct 2020 08:42:47 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux)

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 via email to

[Prev in Thread] Current Thread [Next in Thread]