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: 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.

Let's postpone that for the time being.  I feel that there is still a
basic misunderstanding here.


Do we agree that this bug is all about the "no-backup" case (*C-0* C-x
C-s)?

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.

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.


If I were to write a function replacing `basic-save-buffer-2' just for
that special "no-backup" case, then this way:

  (defun basic-save-buffer-2-no-backup ()
    (interactive)
    ;; ... user confirmation elided here ...
    (setq setmodes (list (file-modes buffer-file-name)
                         (file-extended-attributes buffer-file-name)
                         buffer-file-name))
    ;; No need to call `set-file-extended-attributes' here, since
    ;; we only have one file, and we just got the extended
    ;; attributes from that file.
    (set-file-modes buffer-file-name
                    (logior (car setmodes) 128))
    (let (success)
      (unwind-protect
          (progn
            (write-region nil nil
                          buffer-file-name nil t buffer-file-truename)
            (setq success t))
        (and setmodes (not success)
             (progn
               ;; No sense in calling `rename-file' here as done
               ;; in `basic-save-buffer-2', since we only have
               ;; one file.
               (set-file-extended-attributes buffer-file-name
                                             (nth 1 setmodes))
               (setq buffer-backed-up nil)))))
    setmodes)


>> And wouldn't that be, in this context, just a no-op?
>
> Which part of the above would be a no-op?

Exactly that:

  (set-file-extended-attributes
   buffer-file-name
   (file-extended-attributes buffer-file-name))

We set the extended file attributes on the same file
(`buffer-file-name') where we just got them from (`buffer-file-name').


>> 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?

To restore them after we (possibly) have made the file writable.  Which
we need to do a) when the call to `write-region' has failed (then in
function `basic-save-buffer-2' itself), but also b) when the call has
succeeded (then further up the stack in `basic-save-buffer').


Thanks for your patience!