From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#66546: 30.0.50; save-buffer to write-protected file without backup fails Date: Sat, 14 Oct 2023 22:32:36 +0300 Message-ID: <83h6mtq9t7.fsf@gnu.org> References: Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="4635"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 66546@debbugs.gnu.org To: Jens Schmidt Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sat Oct 14 21:33:56 2023 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1qrkOa-0000wW-Ch for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 14 Oct 2023 21:33:56 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qrkOJ-0001PN-Mp; Sat, 14 Oct 2023 15:33:39 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qrkOI-0001P9-F6 for bug-gnu-emacs@gnu.org; Sat, 14 Oct 2023 15:33:38 -0400 Original-Received: from debbugs.gnu.org ([2001:470:142:5::43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1qrkOI-0000Gi-6v for bug-gnu-emacs@gnu.org; Sat, 14 Oct 2023 15:33:38 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1qrkOf-0007eA-U3 for bug-gnu-emacs@gnu.org; Sat, 14 Oct 2023 15:34:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 14 Oct 2023 19:34:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 66546 X-GNU-PR-Package: emacs Original-Received: via spool by 66546-submit@debbugs.gnu.org id=B66546.169731199429332 (code B ref 66546); Sat, 14 Oct 2023 19:34:01 +0000 Original-Received: (at 66546) by debbugs.gnu.org; 14 Oct 2023 19:33:14 +0000 Original-Received: from localhost ([127.0.0.1]:50576 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qrkNt-0007d1-Ex for submit@debbugs.gnu.org; Sat, 14 Oct 2023 15:33:13 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:52468) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qrkNq-0007cl-Ha for 66546@debbugs.gnu.org; Sat, 14 Oct 2023 15:33:11 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qrkNN-000061-6j; Sat, 14 Oct 2023 15:32:41 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=I1GHrPnoTmFg0yovxH4WjDaapltkn1jE5NKrFcLke5U=; b=hyesE53DfjzN +L7bYfWWFFF2jhFemwTW4bmzCDwMe2OZ/DR+8/QVX430h3wP36yQCJodDl5CS3FtIRd6K4vOOGovj sTnpb/29Wvtvl2OV5sCuxU6VAWLBuB5RSafY2PLumtWv/Xl2c1sbVeIinVevb+b6UIL5m+j+eO1Z1 AM2MsJWKjFYV6rivrAFvGfD+7vnX6/idGFNjKYVE70nhAWulvSQUsq4sfwnqmu+h2QB4KwPW+4pcd SILWMMM33XOqleSEmWI/RVBY1h3FtJHdTCVVbb8itDER1BAtZRJa8zYWOgrmHsH7K4uXxB+R+9ftI 9KjnCgT0/r7lJEuwLE9eCw==; In-Reply-To: (message from Jens Schmidt on Sat, 14 Oct 2023 21:09:53 +0200) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:272465 Archived-At: > Cc: eli zaretskii > Date: Sat, 14 Oct 2023 21:09:53 +0200 > From: Jens Schmidt > > Eli, sorry to disturb you with another edge-case bug, but the commit > that has introduced it was yours It wasn't. > *** Issue A > > In a shell execute: > > echo foo > foo > chmod 0400 foo > ./src/emacs -Q foo > C-x C-q > bar > C-0 C-x C-s > => File foo is write-protected; try to save anyway? > yes RET > => basic-save-buffer-2: Opening output file: Permission denied, > /home/jschmidt/work/emacs-master/foo > > When saving *with* backup, that is, without prefix C-0, everything works > as expected: The file temporarily gets write permissions, gets written > to, and write permissions get removed again. Please explain what happens with "C-0 C-x C-s", and why. I don't think I understand that, given what you wrote. > The root cause is related to Eli's introduction of calls to > `set-file-extended-attributes' in ccad023bc3c7. ccad023bc3c7 didn't introduce set-file-extended-attributes, it wrapped it with with-demoted-errors, and made the code fall back on the traditional set-file-modes when the former call fails. > The marked call [1] is a no-op, since it does not change the permissions > in any way when writing them back, while the call [2] to > `set-file-modes' actually changes the file mode. set-file-modes is supposed to be called only if set-file-extended-attributes fails, unless my reading of the code is incorrect. So again, I don't follow. > Since an extended file attribute Elisp object cannot be modified yet (is > that so?) to mark it, for example, as writable, What do you mean by that? > I propose to just drop that call to `set-file-extended-attributes', > like this: Why does it make sense to ignore the extended attributes here, when we don't ignore them elsewhere in Emacs? > rm -f foo > echo foo > foo > chmod 0400 foo > ./src/emacs -Q > > Define the following advice on `write-region' to simulate a write error: > > ------------------------- snip ------------------------- > (advice-add 'write-region :override > (lambda (&rest _) (error "No space left on device"))) > ------------------------- snip ------------------------- > > Then continue > > C-x C-f foo RET > C-x C-q > bar > C-0 C-x C-s > => File foo is write-protected; try to save anyway? > yes RET > => No space left on device > > Now check the permissions of file foo: > > [emacs-master]$ ls -al foo > -rw------- 1 jschmidt jschmidt 7 Oct 14 20:33 foo > > So the write permissions did not get removed again. > > Here the root cause is that the `unwind-protect' around the > `write-region' in `basic-save-buffer-2' does not handle the no-backup > case separately. I would extend the clean-up form of the > `unwind-protect' to distinguish these both cases and handle the > no-backup case appropriately, here by trying first to set back the > extended attributes, then the regular ones. Fine with me. > I can provide patches for both issues. Plus ERT tests. > > I guess that would be in one changeset, since these are related. Let's revisit this after we have a better understanding of the first issue. I'm not there yet. > Should I provide a separate patch fixing only issue A for emacs-29? Or > is that issue not relevant for emacs-29, given that it went unnoticed > for 12 years? We will not fix this on emacs-29, no matter what. We have lived with these issues for many years, we can live with them for some time longer. So the patches should be for the master branch. Thanks.