[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#66546: 30.0.50; save-buffer to write-protected file without backup f
From: |
Jens Schmidt |
Subject: |
bug#66546: 30.0.50; save-buffer to write-protected file without backup fails |
Date: |
Wed, 18 Oct 2023 22:36:04 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/27.1 (gnu/linux) |
Eli Zaretskii <eliz@gnu.org> writes:
>> From: Jens Schmidt <jschmidt4gnu@vodafonemail.de>
>> Cc: 66546@debbugs.gnu.org
>> Date: Tue, 17 Oct 2023 22:12:58 +0200
>>
>> Eli Zaretskii <eliz@gnu.org> writes:
>>
>> Do we agree that this bug is all about the "no-backup" case (*C-0* C-x
>> C-s)?
>
> The bug is, but basic-save-buffer-2 isn't.
>
>> For me that means: I want to save to file "foo", and I explicitly do not
>> want Emacs to create or touch a backup file "foo~" for that.
>
> While true, I'm not sure what does this have to do with the issue we
> are discussing.
>
>> As a consequence, during the whole operation, there is only _one_ file
>> being involved, and not some second one, both as far as Emacs and the
>> operating system are concerned.
>
> Only if this condition in basic-save-buffer-2 is NOT true:
>
> [...]
>
> Again, I'm not sure why is this relevant.
All of the above is relevant, at least for me, and I'm glad that we
agree up to your corrections, which make sense.
> I think you have an inaccurate mental model of what
> set-file-extended-attributes does. In particular, you seem to think
> that
>
> (set-file-extended-attributes
> buffer-file-name
> (file-extended-attributes buffer-file-name))
>
> leaves the file with the same unchanged extended attributes, as if it
> were a set-file-modes call. But that is not true in general,
> especially if the original owner of the file was not the same user as
> the one who runs the Emacs session that makes these calls. Depending
> on the OS, the actual privileges of the user running Emacs, and the
> file-access setup of the underlying system, the user might not be
> allowed to set some of the attributes, or might become the owner of
> the file, or the OS could add some extended attributes to the original
> ones. So the above is not necessarily a no-op, although in simple
> cases it probably is.
I see, thanks. The one thing I still do not understand is, however:
Why exactly do we need that
(set-file-extended-attributes
buffer-file-name
(file-extended-attributes buffer-file-name))
incantation or the equivalent one
(setq setmodes
(list (file-modes buffer-file-name)
(with-demoted-errors
"Error getting extended attributes: %s"
(file-extended-attributes buffer-file-name))
buffer-file-name))
(with-demoted-errors "Error setting attributes: %s"
(set-file-extended-attributes buffer-file-name
(nth 1 setmodes)))
in function `basic-save-buffer-2'?
That doesn't seem to be a common pattern. There are a few hits for
`set-file-extended-attributes' in the Emacs sources, but they all
attempt to transfer (as far as the OS allows) attributes from one file
to a different one.
In addition, I tried to trace back (this time hopefully correctly) the
origin of this call to `set-file-extended-attributes' and reached this
commit:
574c05e21947 Karel Klíc - Add SELinux support.
Karel added as comment on this function:
(basic-save-buffer-2): Set SELinux context of the newly created file,
and return it.
But we do not have a "newly created file" here, and, in my opinion, do
not need to set an SELinux context/extended attributes on it.
- bug#66546: 30.0.50; save-buffer to write-protected file without backup fails, (continued)
- bug#66546: 30.0.50; save-buffer to write-protected file without backup fails, Jens Schmidt, 2023/10/15
- bug#66546: 30.0.50; save-buffer to write-protected file without backup fails, Eli Zaretskii, 2023/10/15
- bug#66546: 30.0.50; save-buffer to write-protected file without backup fails, Jens Schmidt, 2023/10/15
- bug#66546: 30.0.50; save-buffer to write-protected file without backup fails, Eli Zaretskii, 2023/10/15
- bug#66546: 30.0.50; save-buffer to write-protected file without backup fails, Jens Schmidt, 2023/10/15
- bug#66546: 30.0.50; save-buffer to write-protected file without backup fails, Eli Zaretskii, 2023/10/16
- bug#66546: 30.0.50; save-buffer to write-protected file without backup fails, Jens Schmidt, 2023/10/16
- bug#66546: 30.0.50; save-buffer to write-protected file without backup fails, Eli Zaretskii, 2023/10/17
- bug#66546: 30.0.50; save-buffer to write-protected file without backup fails, Jens Schmidt, 2023/10/17
- bug#66546: 30.0.50; save-buffer to write-protected file without backup fails, Eli Zaretskii, 2023/10/18
- bug#66546: 30.0.50; save-buffer to write-protected file without backup fails,
Jens Schmidt <=
- bug#66546: 30.0.50; save-buffer to write-protected file without backup fails, Eli Zaretskii, 2023/10/19
- bug#66546: 30.0.50; save-buffer to write-protected file without backup fails, Jens Schmidt, 2023/10/19
- bug#66546: 30.0.50; save-buffer to write-protected file without backup fails, Eli Zaretskii, 2023/10/20
- bug#66546: 30.0.50; save-buffer to write-protected file without backup fails, Jens Schmidt, 2023/10/21
- bug#66546: 30.0.50; save-buffer to write-protected file without backup fails, Eli Zaretskii, 2023/10/21
- bug#66546: 30.0.50; save-buffer to write-protected file without backup fails, Jens Schmidt, 2023/10/21
- bug#66546: 30.0.50; save-buffer to write-protected file without backup fails, Eli Zaretskii, 2023/10/22
- bug#66546: 30.0.50; save-buffer to write-protected file without backup fails, Jens Schmidt, 2023/10/22
- bug#66546: 30.0.50; save-buffer to write-protected file without backup fails, Eli Zaretskii, 2023/10/25
- bug#66546: 30.0.50; save-buffer to write-protected file without backup fails, Jens Schmidt, 2023/10/29