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

[Eli Zaretskii]

> From: Jens Schmidt <jschmidt4gnu@vodafonemail.de>
> Cc: 66546@debbugs.gnu.org
> Date: Mon, 16 Oct 2023 22:04:15 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > I've now installed that on the master branch.
> 
> Thanks.  Now that's out of the way, should I then work on what I have
> called issue B in the initial message and on ERT tests for both issues?
> Or do you still think there is more discussion required on these
> beforehand?

I'd like to ask you to show the relevant code again and explain why it
doesn't do the job in that case.

> >> How exactly could above call to `set-file-extended-attributes' *succeed*
> >> to make the file writable?
> >
> > I don't know, and I don't think we should care.  Due to the
> > above-mentioned system-dependencies, Emacs generally treats extended
> > attributes as opaque objects, and only tries hard to preserve them
> > where expected.  So the above is our best effort to preserve the
> > attributes, which is why we call set-file-modes only if absolutely
> > necessary, since doing that in general affects the extended
> > attributes.
> 
> That explains (partially) what I did not understand in your solution.
> But still, to me it seems that the two forms
> 
>   (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)))
> 
> , if limiting them to the extended attribute calls and if ignoring outer
> context, could be simplified to
> 
>   (set-file-extended-attributes
>    buffer-file-name
>    (file-extended-attributes buffer-file-name))
> 
> (If not, why not?)

This is the kind of questions whose answers are in the discussions
that led to the wrapping the calls in with-demoted-errors.  If you
examine the Git history of this code and read the relevant discussions
to which it points, you will realize that the answer is: calling
primitives that access and set extended attributes sometimes fails due
to various subtle issues with those extended attributes, and we don't
want to signal errors in those cases when these primitives are called
from important commands such as the one which saves a buffer to its
visited file, if we can still do the job of saving.

> And wouldn't that be, in this context, just a no-op?

Which part of the above would be a no-op?

> I fully understand that the extended attributes stored in `setmodes' are
> required later to restore the attributes of the file after it has been
> written to.  And in that context I understand why we call
> `set-file-extended-attributes'.  But here not really, yet.

Well, then let me turn the table and ask you: why do you think we need
to restore the extended attributes later? what is the purpose of doing
that?