bug#66546: 30.0.50; save-buffer to write-protected file without backup fails

[Jens Schmidt via "Bug reports for GNU Emacs, the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>]

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.