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: Mon, 16 Oct 2023 14:19:09 +0300 Message-ID: <838r82q0gi.fsf@gnu.org> References: <83h6mtq9t7.fsf@gnu.org> <8734ydx7x3.fsf@sappc2.fritz.box> <83cyxgqwjm.fsf@gnu.org> <87lec4cjqe.fsf@sappc2.fritz.box> <83ttqsp5x1.fsf@gnu.org> <87il78cdyf.fsf@sappc2.fritz.box> <83pm1gozi6.fsf@gnu.org> <87edhvd84h.fsf@sappc2.fritz.box> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="28861"; 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 Mon Oct 16 13:20: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 1qsLea-0007Dp-1o for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 16 Oct 2023 13:20:56 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qsLeJ-0007RE-Vq; Mon, 16 Oct 2023 07:20:40 -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 1qsLeI-0007QY-E9 for bug-gnu-emacs@gnu.org; Mon, 16 Oct 2023 07:20: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 1qsLeI-0006KY-3V for bug-gnu-emacs@gnu.org; Mon, 16 Oct 2023 07:20:38 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1qsLeg-0002qw-K2 for bug-gnu-emacs@gnu.org; Mon, 16 Oct 2023 07:21:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 16 Oct 2023 11:21:02 +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.169745521610878 (code B ref 66546); Mon, 16 Oct 2023 11:21:02 +0000 Original-Received: (at 66546) by debbugs.gnu.org; 16 Oct 2023 11:20:16 +0000 Original-Received: from localhost ([127.0.0.1]:55382 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qsLdw-0002pO-5z for submit@debbugs.gnu.org; Mon, 16 Oct 2023 07:20:16 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:32858) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qsLdt-0002p6-Ay for 66546@debbugs.gnu.org; Mon, 16 Oct 2023 07:20:14 -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 1qsLdM-0005vV-Qo; Mon, 16 Oct 2023 07:19:42 -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=bMUCFwjZG/lgqA9VJd8lGjehiW7scGNR8AwqGHc6rRk=; b=UhY/jsSxwXWv JtFkcEyT22yslgUSepoDhQrPeAO0sJZ0HRHZAOYCzmRp59JW8nbP+3/pdt3xYWa7gZv4os3l6Uf0O wr0CWyRnFsNtOD2bw3CfahpU7lyNVRMnsl15woYzb3CXWbom5SLKcTeQKWcVsoyiugmqPKDEXduqn StRSi4w2/GbxBS9pTNP75Z9fXfckLO3D6Xhh4SCZeR+vH5+6dH579bBGdSdaaNWUnGwTZAavQ3x/w ar1EWP1nkTipWWwKJIqZaTMJtZRC+6dZ86zEMrEWDkh1/MeeKLESLgxWDcJNZ/znG8nA0smKkTAID 9umeTBUAVfQsETV9QPV6Vg==; In-Reply-To: <87edhvd84h.fsf@sappc2.fritz.box> (message from Jens Schmidt on Sun, 15 Oct 2023 20:59:42 +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:272560 Archived-At: > From: Jens Schmidt > Cc: 66546@debbugs.gnu.org > Date: Sun, 15 Oct 2023 20:59:42 +0200 > > Eli Zaretskii writes: > > > In that case, does the change below fix the original problem? > > It does, thanks. I've now installed that on the master branch. > >> Using *only* the extended-attribute Elisp functions and objects, is > >> there currently a way to implement the equivalent of "chmod u+w FILE" in > >> Elisp? > > > AFAIU, this question has no meaningful answer. Extended attributes > > are much more fine-grained than the "traditional" file mode bits; in > > particular, they are incompatible with the "user" notion to fit the > > "u" part of "u+w": the same file can be writable by a specific user or > > group of users, and unwritable by others. Even if you only limit > > yourself to Posix extended attributes (and Emacs doesn't limit itself > > to that), there's no good answer to your question. > > Then pls let me ask a more general question. Given a sequence > > (setq ext-attrs (file-extended-attributes file-name)) > (setq ext-attrs (funcall func ext-attrs)) > (set-file-extended-attributes file-name ext-attrs) > > is there any Elisp function FUNC so that the extended attributes on > FILE-NAME as seen by the OS change by executing that sequence? The only way I know of is to edit the extended attributes, which are returned as a string, then use those edited attributes. But the semantics, and therefore the editing, of those strings are platform-dependent, and editing them requires intimate knowledge of the semantics and which edits are valid. > > + ;; If set-file-extended-attributes fails to make the > > + ;; file writable, fall back on set-file-modes. > > + (with-demoted-errors "Error setting attributes: %s" > > + (set-file-extended-attributes buffer-file-name > > + (nth 1 setmodes))) > > 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.