From unknown Fri Jun 20 18:09:44 2025 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailer: MIME-tools 5.509 (Entity 5.509) Content-Type: text/plain; charset=utf-8 From: bug#21699 <21699@debbugs.gnu.org> To: bug#21699 <21699@debbugs.gnu.org> Subject: Status: 24.5; Bug in backup-buffer-copy and/or set-file-extended-attributes etc Reply-To: bug#21699 <21699@debbugs.gnu.org> Date: Sat, 21 Jun 2025 01:09:44 +0000 retitle 21699 24.5; Bug in backup-buffer-copy and/or set-file-extended-attr= ibutes etc reassign 21699 emacs submitter 21699 Eli Barzilay severity 21699 normal thanks From debbugs-submit-bounces@debbugs.gnu.org Sun Oct 18 00:35:09 2015 Received: (at submit) by debbugs.gnu.org; 18 Oct 2015 04:35:10 +0000 Received: from localhost ([127.0.0.1]:54717 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Znfgb-00076S-D2 for submit@debbugs.gnu.org; Sun, 18 Oct 2015 00:35:09 -0400 Received: from eggs.gnu.org ([208.118.235.92]:43090) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZnfgZ-00076J-Cy for submit@debbugs.gnu.org; Sun, 18 Oct 2015 00:35:08 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZnfgX-0007Zy-Np for submit@debbugs.gnu.org; Sun, 18 Oct 2015 00:35:06 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50 autolearn=disabled version=3.3.2 Received: from lists.gnu.org ([2001:4830:134:3::11]:55411) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZnfgX-0007Zq-LL for submit@debbugs.gnu.org; Sun, 18 Oct 2015 00:35:05 -0400 Received: from eggs.gnu.org ([2001:4830:134:3::10]:53082) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZnfgW-0003hv-Da for bug-gnu-emacs@gnu.org; Sun, 18 Oct 2015 00:35:05 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZnfgR-0007Um-CY for bug-gnu-emacs@gnu.org; Sun, 18 Oct 2015 00:35:04 -0400 Received: from mail-wi0-f176.google.com ([209.85.212.176]:36415) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZnfgR-0007UZ-6m for bug-gnu-emacs@gnu.org; Sun, 18 Oct 2015 00:34:59 -0400 Received: by wicfx6 with SMTP id fx6so9092532wic.1 for ; Sat, 17 Oct 2015 21:34:58 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:mime-version:content-type :content-transfer-encoding:message-id:date:to:subject; bh=h9H5carjL+ZCGmsowQ8KwQgz0FwKuCSG06hZsHrdbAg=; b=bbF8MMdBq/lILEwuZ+mhfuQZ4ojh2/IuGAQGKVhkXp+8VAbYAxJyBzpU8Lg/wIWVQ2 G/n44ySoI5TcZLkLplVozWW0qJDtxhVN9UgI1R3waaMx7urfe6oBemP1S/7eajI4/Kr4 bLxJZ4DK7BsDealf/lyuab3B00n3QTR0dLeWN+Lu+uqA/gnxIV+euO8MKCbtaRaaLTKy YugskxaGm5JSE16Py35crwvYi1bEm6lwzYIlEpYITf6rcJwvfapDceZi2nxoLwHidzjF yyVnL0JQbLIAKainGsclv3ayPnDEYsJ2ohtk+RIrXLle5x32lD+nhBdkEceq0+HLBaS2 bn8A== X-Gm-Message-State: ALoCoQlWE2Hw7SDlVEl8O1Ocym/RhGRVSi2ai/ohr8xe5ANvWIR4SEECNkBIcJhf60NXkoHsD2WS X-Received: by 10.194.113.101 with SMTP id ix5mr26041576wjb.107.1445142898459; Sat, 17 Oct 2015 21:34:58 -0700 (PDT) Received: from BARZILAY ([178.208.171.1]) by smtp.gmail.com with ESMTPSA id ki7sm31877149wjc.28.2015.10.17.21.34.56 for (version=TLSv1/SSLv3 cipher=OTHER); Sat, 17 Oct 2015 21:34:57 -0700 (PDT) From: Eli Barzilay MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <22051.8546.40000.221633@gargle.gargle.HOWL> Date: Sun, 18 Oct 2015 00:34:42 -0400 To: bug-gnu-emacs@gnu.org Subject: 24.5; Bug in backup-buffer-copy and/or set-file-extended-attributes etc X-Mailer: VM 8.2.0a under 24.5.1 (i686-pc-mingw32) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2001:4830:134:3::11 X-Spam-Score: -4.0 (----) X-Debbugs-Envelope-To: submit X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -4.0 (----) (There are potentially multiple bugs here, I'll mark them as [n].) After switching to 24.5 I started to see warnings like: Cannot write backup file; backing up in ~/.emacs.d/%backup%~ when saving a file on a remote directory (running on Windows, remote is on Linux, but this is unlikely to be relevant). I tracked this to `backup-buffer-copy', which has a seemingly bad use of `with-demoted-errors'. This looks like a minor update is needed [1], since the macro source handles a no-format-string case as legacy. The next suspect was `set-file-extended-attributes'. This code comes from commit ccad023bc3c70fc8368c00f7ed2f5ec947a4260d (2012-12-29), and following the description there, I think that there's a bug in this function: it has a single `dolist' which would always return nil, which means that putting it in the `and' of `backup-buffer-copy' makes the code always think that there was a failure. Instead, there should be some flag to be used in the loop to keep track of the `and' of all of the results [2]. (Or maybe there's some andmap/every/... function that does it more idiomatically.) Next comes `set-file-selinux-context', which might have a problem. It's documentation says: This function does nothing and returns nil if SELinux is disabled, or if Emacs was not compiled with SELinux support. which I assume is my case since I'm running on Windows. It is called with (nil nil nil nil) which I'm guessing is some no-information- since-we-don't-have-selinux thing -- but in that case, `set-file-selinux-context' should not return nil when it's getting that value. So something is definitely broken here [3], either it shouldn't return nil, or it shouldn't be called (avoid adding that 4xnil value to the extended-attributes, or avoid calling `set-file-selinux-context' with that value), and possibly there should be an explicit no-info value. Finally, after the above problem makes it think that there was a failure, it uses `set-file-modes' with the backup file, and that throws an error for the backup file: (file-error "Doing chmod" "permission denied" "...path-to-backup...") My setup is to have a single (local) directory for backups, so this might be some result of applying the windows acl thing first, copying the acl of the remote file to the one of the local backup. Windows shows that the file permissions for Everyone are: "Read & Execute" and "Read", so that might be the problem. I'm not sure how this whole thing will look like, but it might be a problem to apply the acls this way, so this problem might require some additional flag that allows people to avoid copying the acls to the backups. -- ((x=>x(x))(x=>x(x))) Eli Barzilay: http://barzilay.org/ Maze is Life! From debbugs-submit-bounces@debbugs.gnu.org Sun Oct 18 12:01:40 2015 Received: (at 21699) by debbugs.gnu.org; 18 Oct 2015 16:01:40 +0000 Received: from localhost ([127.0.0.1]:55285 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZnqOy-0007oq-1W for submit@debbugs.gnu.org; Sun, 18 Oct 2015 12:01:40 -0400 Received: from mtaout21.012.net.il ([80.179.55.169]:54153) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZnqOw-0007oi-2L for 21699@debbugs.gnu.org; Sun, 18 Oct 2015 12:01:39 -0400 Received: from conversion-daemon.a-mtaout21.012.net.il by a-mtaout21.012.net.il (HyperSendmail v2007.08) id <0NWF00000B65J900@a-mtaout21.012.net.il> for 21699@debbugs.gnu.org; Sun, 18 Oct 2015 19:01:36 +0300 (IDT) Received: from HOME-C4E4A596F7 ([84.94.185.246]) by a-mtaout21.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NWF000DPB6NEHA0@a-mtaout21.012.net.il>; Sun, 18 Oct 2015 19:01:36 +0300 (IDT) Date: Sun, 18 Oct 2015 19:01:36 +0300 From: Eli Zaretskii Subject: Re: bug#21699: 24.5; Bug in backup-buffer-copy and/or set-file-extended-attributes etc In-reply-to: <22051.8546.40000.221633@gargle.gargle.HOWL> X-012-Sender: halo1@inter.net.il To: Eli Barzilay Message-id: <83wpuki2sf.fsf@gnu.org> References: <22051.8546.40000.221633@gargle.gargle.HOWL> X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 21699 Cc: 21699@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) > From: Eli Barzilay > Date: Sun, 18 Oct 2015 00:34:42 -0400 > > (There are potentially multiple bugs here, I'll mark them as [n].) > > After switching to 24.5 I started to see warnings like: > > Cannot write backup file; backing up in ~/.emacs.d/%backup%~ > > when saving a file on a remote directory (running on Windows, remote > is on Linux, but this is unlikely to be relevant). > > I tracked this to `backup-buffer-copy', which has a seemingly bad use > of `with-demoted-errors'. Do you mean to say that backup-buffer-copy fails in your case? If so, it means you have some customizations, or maybe the way your volume is mounted causes backup-buffer-copy be called. It isn't normally called in "emacs -Q" and with local files, AFAICT. Is that what happens in your case? Do you see the problem in "emacs -Q"? > The next suspect was `set-file-extended-attributes'. This code comes > from commit ccad023bc3c70fc8368c00f7ed2f5ec947a4260d (2012-12-29), and > following the description there, I think that there's a bug in this > function: it has a single `dolist' which would always return nil, > which means that putting it in the `and' of `backup-buffer-copy' makes > the code always think that there was a failure. Instead, there should > be some flag to be used in the loop to keep track of the `and' of all > of the results [2]. (Or maybe there's some andmap/every/... function > that does it more idiomatically.) > > Next comes `set-file-selinux-context', which might have a problem. > It's documentation says: > > This function does nothing and returns nil if SELinux is disabled, > or if Emacs was not compiled with SELinux support. > > which I assume is my case since I'm running on Windows. It is called > with (nil nil nil nil) which I'm guessing is some no-information- > since-we-don't-have-selinux thing -- but in that case, > `set-file-selinux-context' should not return nil when it's getting > that value. So something is definitely broken here [3], either it > shouldn't return nil, or it shouldn't be called (avoid adding that > 4xnil value to the extended-attributes, or avoid calling > `set-file-selinux-context' with that value), and possibly there should > be an explicit no-info value. > > Finally, after the above problem makes it think that there was a > failure, it uses `set-file-modes' with the backup file, and that > throws an error for the backup file: > > (file-error "Doing chmod" "permission denied" "...path-to-backup...") > > My setup is to have a single (local) directory for backups, so this > might be some result of applying the windows acl thing first, copying > the acl of the remote file to the one of the local backup. Windows > shows that the file permissions for Everyone are: "Read & Execute" and > "Read", so that might be the problem. I'm not sure how this whole > thing will look like, but it might be a problem to apply the acls this > way, so this problem might require some additional flag that allows > people to avoid copying the acls to the backups. Thanks for looking into this. I don't think there are so many problems in those functions. I suggest to step with Edebug into backup-buffer and its subroutines, or maybe just into backup-buffer-copy, if you are sure it's the failing function, and establish for sure which of them fails and why. Then we could take it from there. My first guess would be some snafu in Windows permissions caused by the method you used to mount the GNU/Linux volume. But before I start asking you for further information based on that hypothesis, I'd like to be sure this is indeed the cause of your problems. From debbugs-submit-bounces@debbugs.gnu.org Sun Oct 18 17:05:49 2015 Received: (at 21699) by debbugs.gnu.org; 18 Oct 2015 21:05:49 +0000 Received: from localhost ([127.0.0.1]:55451 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Znv9I-0008Iw-HZ for submit@debbugs.gnu.org; Sun, 18 Oct 2015 17:05:49 -0400 Received: from mail-ig0-f172.google.com ([209.85.213.172]:34777) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Znv9E-0008Il-Me for 21699@debbugs.gnu.org; Sun, 18 Oct 2015 17:05:45 -0400 Received: by igbni9 with SMTP id ni9so43025158igb.1 for <21699@debbugs.gnu.org>; Sun, 18 Oct 2015 14:05:44 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=mRKX3cRYH48wXVLkJb3YsBNysxkycr7qzu7XarZ1hLI=; b=RDMS5Xz1GSwZtvXWHaRE/aIONTn9c0jjcEPLfODe5uC0lRZF5E/XJTmgc5uOmEF7IV ilajmkp8pkdFCpQVyRIy0/5a9lQOUuubosI2GL8L3qZMJVii8CI2VP9zM4UdUeaKOTrp dTqjgz1JP/PiOGU4Kokzbfqq75Fnx3FZQTyOZ2XJlppQOs+PyrdPeRw1S60ah8Enbdku 6kVj2K3pNF5VELRkLqx032AmEXJGYvdKbuR0zIadG5Py9lL/Ez6TwK1drQjSFO0Q7uo/ cbzfn7Txp4DG61QFtwdpK1b2oyfkHy4Z8oMJOtp5FsgCmDJBL//ZHGW4qTYqyQWuiSQU W05w== X-Gm-Message-State: ALoCoQmph7JA/23Nc+nBLANXuie4d0jC1rgin6wpbHgFyoMz/t/ojhNR1ywNtVko3A4hsk74Z0W4 MIME-Version: 1.0 X-Received: by 10.50.39.52 with SMTP id m20mr10211185igk.60.1445202343873; Sun, 18 Oct 2015 14:05:43 -0700 (PDT) Received: by 10.79.28.211 with HTTP; Sun, 18 Oct 2015 14:05:43 -0700 (PDT) In-Reply-To: <83wpuki2sf.fsf@gnu.org> References: <22051.8546.40000.221633@gargle.gargle.HOWL> <83wpuki2sf.fsf@gnu.org> Date: Sun, 18 Oct 2015 17:05:43 -0400 Message-ID: Subject: Re: bug#21699: 24.5; Bug in backup-buffer-copy and/or set-file-extended-attributes etc From: Eli Barzilay To: Eli Zaretskii Content-Type: text/plain; charset=UTF-8 X-Spam-Score: 0.3 (/) X-Debbugs-Envelope-To: 21699 Cc: 21699@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.3 (/) On Sun, Oct 18, 2015 at 12:01 PM, Eli Zaretskii wrote: > > Do you mean to say that backup-buffer-copy fails in your case? If so, > it means you have some customizations, or maybe the way your volume is > mounted causes backup-buffer-copy be called. It isn't normally called > in "emacs -Q" and with local files, AFAICT. > > Is that what happens in your case? > > Do you see the problem in "emacs -Q"? Yes, I do have customizations. Overall I'm not doing anything that should be done -- though I'm guessing that not many people get to that situation. The main thing in my setup is that backups are done by copying the file into a single directory for backups -- and in the problem case the backup is on a local windows directory when the original file is coming from a remote mount (on linux). But the bugs are easy to see: 1. `with-demoted-errors' is used in a bunch of places without a format string. This is not a bug since the macro supports the case of a non-literal-string being the first expression, but's for legacy, so it's either better to add that format string, or the macro should support that without qualifying it as a legacy feature. 2. The `set-file-extended-attributes' function always returns nil, which is a proper bug: - In `backup-buffer-copy' its return value is used as if it indicates whether it succeeded -- that's currently broken because it always returns nil. - It's also used in `basic-save-buffer' -- but there its result is not used, and the code looks like it's expecting it to throw an error on failure. - It's also used in `basic-save-buffer-2', in a `with-demoted-errors' The commit message that I pointed to makes me think that it's expected to return nil on failure -- so it should be fixed to do that. Another solution would be if it's expected to throw an error when it fails, and in this case the first use is broken and should not look at its result. 3. The third problem happens *if* the solution to #2 is to make it return a meaningful result. In that case, the problem I'll run into is that on windows my extended modes include (selinux nil nil nil nil) which I'm guessing is because there's no selinux support, but then `set-file-selinux-context' should not fail when getting a value of (nil nil nil nil). 4. The last problem of chmod-ing failing after setting the windows acl is probably better to defer after resolving the above. -- ((x=>x(x))(x=>x(x))) Eli Barzilay: http://barzilay.org/ Maze is Life! From debbugs-submit-bounces@debbugs.gnu.org Mon Oct 19 01:10:45 2015 Received: (at 21699) by debbugs.gnu.org; 19 Oct 2015 05:10:45 +0000 Received: from localhost ([127.0.0.1]:55574 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Zo2ia-0002Wj-Ic for submit@debbugs.gnu.org; Mon, 19 Oct 2015 01:10:45 -0400 Received: from mtaout22.012.net.il ([80.179.55.172]:54261) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Zo2iW-0002WZ-KQ for 21699@debbugs.gnu.org; Mon, 19 Oct 2015 01:10:42 -0400 Received: from conversion-daemon.a-mtaout22.012.net.il by a-mtaout22.012.net.il (HyperSendmail v2007.08) id <0NWG00800BIF4C00@a-mtaout22.012.net.il> for 21699@debbugs.gnu.org; Mon, 19 Oct 2015 08:10:39 +0300 (IDT) Received: from HOME-C4E4A596F7 ([84.94.185.246]) by a-mtaout22.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NWG008GEBPQ3H20@a-mtaout22.012.net.il>; Mon, 19 Oct 2015 08:10:39 +0300 (IDT) Date: Mon, 19 Oct 2015 08:10:40 +0300 From: Eli Zaretskii Subject: Re: bug#21699: 24.5; Bug in backup-buffer-copy and/or set-file-extended-attributes etc In-reply-to: X-012-Sender: halo1@inter.net.il To: Eli Barzilay Message-id: <838u6zigtr.fsf@gnu.org> References: <22051.8546.40000.221633@gargle.gargle.HOWL> <83wpuki2sf.fsf@gnu.org> X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 21699 Cc: 21699@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) > Date: Sun, 18 Oct 2015 17:05:43 -0400 > From: Eli Barzilay > Cc: 21699@debbugs.gnu.org > > On Sun, Oct 18, 2015 at 12:01 PM, Eli Zaretskii wrote: > > > > Do you mean to say that backup-buffer-copy fails in your case? If so, > > it means you have some customizations, or maybe the way your volume is > > mounted causes backup-buffer-copy be called. It isn't normally called > > in "emacs -Q" and with local files, AFAICT. > > > > Is that what happens in your case? > > > > Do you see the problem in "emacs -Q"? > > Yes, I do have customizations. Overall I'm not doing anything that > should be done -- though I'm guessing that not many people get to that > situation. The main thing in my setup is that backups are done by > copying the file into a single directory for backups -- and in the > problem case the backup is on a local windows directory when the > original file is coming from a remote mount (on linux). Please do tell if the problem happens in "emacs -Q". We need to start from same baseline which we understand. It might be better to also show the results in "emacs -Q" when backup-by-copying is non-nil, but with local files on a Windows volume. Btw, what kind of volume is your Windows disk where you have the backup directory? Is it NTFS, FAT32, something else? Also, I need the results of calling file-attributes and file-acl on the file for which backup fails and on the backup directory. > 2. The `set-file-extended-attributes' function always returns nil, which > is a proper bug: > - In `backup-buffer-copy' its return value is used as if it indicates > whether it succeeded -- that's currently broken because it always > returns nil. That's not a bug: set-file-extended-attributes is not supposed to always return nil. When it succeeds, it returns t. It returns nil in your case because it fails; the question is why. > - It's also used in `basic-save-buffer' -- but there its result is > not used, and the code looks like it's expecting it to throw an > error on failure. That's not a bug, either: set-file-extended-attributes does signal an error when it fails. In backup-buffer-copy it is prevented from signaling an error by with-demoted-errors. > - It's also used in `basic-save-buffer-2', in a `with-demoted-errors' > The commit message that I pointed to makes me think that it's > expected to return nil on failure -- so it should be fixed to do > that. Another solution would be if it's expected to throw an error > when it fails, and in this case the first use is broken and should > not look at its result. See above: these are not bugs, but intended behavior. The question is why the function fails in your case. That is one reason why I asked to see the results in "emacs -Q" > 3. The third problem happens *if* the solution to #2 is to make it > return a meaningful result. In that case, the problem I'll run into > is that on windows my extended modes include > > (selinux nil nil nil nil) > > which I'm guessing is because there's no selinux support, but then > `set-file-selinux-context' should not fail when getting a value of > (nil nil nil nil). set-file-selinux-context is not supposed to be called on MS-Windows, because SELinux APIs are not supported there. > 4. The last problem of chmod-ing failing after setting the windows acl > is probably better to defer after resolving the above. That's a big surprise: chmod is largely a no-op on Windows. If you invoke set-file-modes exactly like backup-buffer-copy does, but from the "M-:" prompt, what error does it report? Are you sure backup-buffer-copy even copies the file to the backup directory? IOW, does the call to copy-file inside backup-buffer-copy work? If it does not, that would explain why both set-file-extended-attributes and set-file-modes fail afterwards. So perhaps manually running the code of backup-buffer-copy step by step with a file on your Linux volume would show where the failure starts. From debbugs-submit-bounces@debbugs.gnu.org Mon Oct 19 02:14:43 2015 Received: (at 21699) by debbugs.gnu.org; 19 Oct 2015 06:14:43 +0000 Received: from localhost ([127.0.0.1]:55625 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Zo3iU-00045x-RG for submit@debbugs.gnu.org; Mon, 19 Oct 2015 02:14:43 -0400 Received: from mail-ig0-f176.google.com ([209.85.213.176]:38221) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Zo3iS-00045p-VA for 21699@debbugs.gnu.org; Mon, 19 Oct 2015 02:14:41 -0400 Received: by igbdj2 with SMTP id dj2so50060905igb.1 for <21699@debbugs.gnu.org>; Sun, 18 Oct 2015 23:14:40 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to:cc :content-type; bh=O8ISpa8yNaL7vO8rdvTgi3ygppC2vtTKbkmMBZC2RRc=; b=CjuX60dnrDoDnChuqE70wrjpxhwN/h/IkSHkxk8bB2JisEPLRmxmXH72NLQSNB82Cn smQ25zwf7IG3wLpkjU28XO7MIkCiHbFjCuLJB0FIZuMD4lEzwXUtOhHAnUbUi4wqMMG5 HN/BtaEZCHKITy8/Lz75c04sFJ51QfcrzboP5Ve2KNdg8YDBlDzKYIvwpeTdeObR1D1A nM5IDOEjhxF7sXHsiXPpUMn+fxOyNHsvN471I+i/doiQvT1fO7Bsyp1oLctqi8EAr5Jd mfoPs7jBW01UHZDRfezDzkM/HRcd+HdmcfcPi2iLGb+9WwCFMmixoa2TN5JNB2f9ZViX TFLA== X-Gm-Message-State: ALoCoQm22khbAR3xtyFjxa+CmIIZyzp19giNEI41YaUKRmqR9VpE53T5/nHrbqp6v21abRdBCO7i MIME-Version: 1.0 X-Received: by 10.50.137.97 with SMTP id qh1mr17747142igb.60.1445235280347; Sun, 18 Oct 2015 23:14:40 -0700 (PDT) Received: by 10.79.28.211 with HTTP; Sun, 18 Oct 2015 23:14:40 -0700 (PDT) Date: Mon, 19 Oct 2015 02:14:40 -0400 Message-ID: Subject: Re: bug#21699: 24.5; Bug in backup-buffer-copy and/or set-file-extended-attributes etc [set-file-extended-attributes] From: Eli Barzilay To: Eli Zaretskii Content-Type: text/plain; charset=UTF-8 X-Spam-Score: 0.3 (/) X-Debbugs-Envelope-To: 21699 Cc: 21699@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.3 (/) On Mon, Oct 19, 2015 at 1:10 AM, Eli Zaretskii wrote: >> >> On Sun, Oct 18, 2015 at 12:01 PM, Eli Zaretskii wrote: >> > >> > Do you mean to say that backup-buffer-copy fails in your case? If so, >> > it means you have some customizations, or maybe the way your volume is >> > mounted causes backup-buffer-copy be called. It isn't normally called >> > in "emacs -Q" and with local files, AFAICT. >> > >> > Is that what happens in your case? >> > >> > Do you see the problem in "emacs -Q"? >> >> Yes, I do have customizations. Overall I'm not doing anything that >> should be done -- though I'm guessing that not many people get to that >> situation. The main thing in my setup is that backups are done by >> copying the file into a single directory for backups -- and in the >> problem case the backup is on a local windows directory when the >> original file is coming from a remote mount (on linux). > > Please do tell if the problem happens in "emacs -Q". We need to start > from same baseline which we understand. It might be better to also > show the results in "emacs -Q" when backup-by-copying is non-nil, but > with local files on a Windows volume. Getting from -Q to a point where the bug(s) are visible means recreating the same backup configuration which will take a while. I'll try to get that kater, though I don't know how effective that will be. The main bug is very visible though, but perhaps it got lost in details. So I'll talk about just that now. (I'll update the subject accordingly.) >> 2. The `set-file-extended-attributes' function always returns nil, >> which is a proper bug: >> - In `backup-buffer-copy' its return value is used as if it >> indicates whether it succeeded -- that's currently broken >> because it always returns nil. > > That's not a bug: set-file-extended-attributes is not supposed to > always return nil. Yes, I'm saying that it *does* AFAICT always return nil, hence the bug. > When it succeeds, it returns t. It returns nil in your case because > it fails; the question is why. Its body is a single `dotimes' expression, and that always returns nil -- do you see any way in which it will return anything else? As a trivial test, I ran this: (set-file-extended-attributes ".emacs" nil) and the result is the expected nil. Fixing this bug, AFAICT, should look like (defun set-file-extended-attributes (filename attributes) "..." (let ((res t)) (dolist (elt attributes) (let ((attr (car elt)) (val (cdr elt))) (unless (cond ((eq attr 'acl) (set-file-acl filename val)) ((eq attr 'selinux-context) (set-file-selinux-context filename val))) (setq res nil)))) res)) -- ((x=>x(x))(x=>x(x))) Eli Barzilay: http://barzilay.org/ Maze is Life! From debbugs-submit-bounces@debbugs.gnu.org Mon Oct 19 02:39:02 2015 Received: (at 21699) by debbugs.gnu.org; 19 Oct 2015 06:39:02 +0000 Received: from localhost ([127.0.0.1]:55634 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Zo461-0004f5-9a for submit@debbugs.gnu.org; Mon, 19 Oct 2015 02:39:01 -0400 Received: from mtaout28.012.net.il ([80.179.55.184]:59546) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Zo45x-0004et-JO for 21699@debbugs.gnu.org; Mon, 19 Oct 2015 02:38:59 -0400 Received: from conversion-daemon.mtaout28.012.net.il by mtaout28.012.net.il (HyperSendmail v2007.08) id <0NWG00D00FOSBZ00@mtaout28.012.net.il> for 21699@debbugs.gnu.org; Mon, 19 Oct 2015 09:37:21 +0300 (IDT) Received: from HOME-C4E4A596F7 ([84.94.185.246]) by mtaout28.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NWG00221FQ822B0@mtaout28.012.net.il>; Mon, 19 Oct 2015 09:37:20 +0300 (IDT) Date: Mon, 19 Oct 2015 09:38:08 +0300 From: Eli Zaretskii Subject: Re: bug#21699: 24.5; Bug in backup-buffer-copy and/or set-file-extended-attributes etc [set-file-extended-attributes] In-reply-to: X-012-Sender: halo1@inter.net.il To: Eli Barzilay Message-id: <831tcricrz.fsf@gnu.org> References: X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 21699 Cc: 21699@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) > Date: Mon, 19 Oct 2015 02:14:40 -0400 > From: Eli Barzilay > Cc: 21699@debbugs.gnu.org > > > Please do tell if the problem happens in "emacs -Q". We need to start > > from same baseline which we understand. It might be better to also > > show the results in "emacs -Q" when backup-by-copying is non-nil, but > > with local files on a Windows volume. > > Getting from -Q to a point where the bug(s) are visible means recreating > the same backup configuration which will take a while. I'll try to get > that kater, though I don't know how effective that will be. Please do, I think it's important to start from a known behavior that we understand. > >> 2. The `set-file-extended-attributes' function always returns nil, > >> which is a proper bug: > >> - In `backup-buffer-copy' its return value is used as if it > >> indicates whether it succeeded -- that's currently broken > >> because it always returns nil. > > > > That's not a bug: set-file-extended-attributes is not supposed to > > always return nil. > > Yes, I'm saying that it *does* AFAICT always return nil, hence the bug. > > > > When it succeeds, it returns t. It returns nil in your case because > > it fails; the question is why. > > Its body is a single `dotimes' expression, and that always returns nil > -- do you see any way in which it will return anything else? Ah, yes, you are right. I was instead looking at what set-file-acl returns. So after fixing set-file-extended-attributes as you suggest, does the problem still happen for you? From debbugs-submit-bounces@debbugs.gnu.org Mon Oct 19 02:50:08 2015 Received: (at 21699) by debbugs.gnu.org; 19 Oct 2015 06:50:08 +0000 Received: from localhost ([127.0.0.1]:55641 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Zo4Gm-0004vP-85 for submit@debbugs.gnu.org; Mon, 19 Oct 2015 02:50:08 -0400 Received: from mtaout25.012.net.il ([80.179.55.181]:50543) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Zo4Gj-0004vG-AD for 21699@debbugs.gnu.org; Mon, 19 Oct 2015 02:50:06 -0400 Received: from conversion-daemon.mtaout25.012.net.il by mtaout25.012.net.il (HyperSendmail v2007.08) id <0NWG00G00G1MDG00@mtaout25.012.net.il> for 21699@debbugs.gnu.org; Mon, 19 Oct 2015 09:47:43 +0300 (IDT) Received: from HOME-C4E4A596F7 ([84.94.185.246]) by mtaout25.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NWG009JSG7I9L70@mtaout25.012.net.il>; Mon, 19 Oct 2015 09:47:43 +0300 (IDT) Date: Mon, 19 Oct 2015 09:50:06 +0300 From: Eli Zaretskii Subject: Re: bug#21699: 24.5; Bug in backup-buffer-copy and/or set-file-extended-attributes etc [set-file-extended-attributes] In-reply-to: <831tcricrz.fsf@gnu.org> X-012-Sender: halo1@inter.net.il To: eli@barzilay.org Message-id: <83zizfgxnl.fsf@gnu.org> References: <831tcricrz.fsf@gnu.org> X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 21699 Cc: 21699@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) > Date: Mon, 19 Oct 2015 09:38:08 +0300 > From: Eli Zaretskii > Cc: 21699@debbugs.gnu.org > > So after fixing set-file-extended-attributes as you suggest, does the > problem still happen for you? Actually, your suggested variant also returns nil for me. I need something like this instead: (defun set-file-extended-attributes (filename attributes) "Set extended attributes of file FILENAME to ATTRIBUTES. ATTRIBUTES must be an alist of file attributes as returned by `file-extended-attributes'." (let (result) (dolist (elt attributes) (let ((attr (car elt)) (val (cdr elt))) (cond ((eq attr 'acl) (setq result (or result (set-file-acl filename val)))) ((eq attr 'selinux-context) (setq result (or result (set-file-selinux-context filename val))))))) result)) With this change, evaluating (set-file-extended-attributes "~/.emacs" (file-extended-attributes "~/.emacs") returns t here. From debbugs-submit-bounces@debbugs.gnu.org Mon Oct 19 03:09:54 2015 Received: (at 21699) by debbugs.gnu.org; 19 Oct 2015 07:09:54 +0000 Received: from localhost ([127.0.0.1]:55651 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Zo4Zu-0005P5-2g for submit@debbugs.gnu.org; Mon, 19 Oct 2015 03:09:54 -0400 Received: from mtaout20.012.net.il ([80.179.55.166]:40809) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Zo4Zr-0005Ot-A8 for 21699@debbugs.gnu.org; Mon, 19 Oct 2015 03:09:52 -0400 Received: from conversion-daemon.a-mtaout20.012.net.il by a-mtaout20.012.net.il (HyperSendmail v2007.08) id <0NWG00600H7BAZ00@a-mtaout20.012.net.il> for 21699@debbugs.gnu.org; Mon, 19 Oct 2015 10:09:34 +0300 (IDT) Received: from HOME-C4E4A596F7 ([84.94.185.246]) by a-mtaout20.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NWG006HQH7X1250@a-mtaout20.012.net.il>; Mon, 19 Oct 2015 10:09:34 +0300 (IDT) Date: Mon, 19 Oct 2015 10:09:36 +0300 From: Eli Zaretskii Subject: Re: bug#21699: 24.5; Bug in backup-buffer-copy and/or set-file-extended-attributes etc [set-file-extended-attributes] In-reply-to: <83zizfgxnl.fsf@gnu.org> X-012-Sender: halo1@inter.net.il To: eli@barzilay.org Message-id: <83wpujgwr3.fsf@gnu.org> References: <831tcricrz.fsf@gnu.org> <83zizfgxnl.fsf@gnu.org> X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 21699 Cc: 21699@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) > Date: Mon, 19 Oct 2015 09:50:06 +0300 > From: Eli Zaretskii > Cc: 21699@debbugs.gnu.org > > > Date: Mon, 19 Oct 2015 09:38:08 +0300 > > From: Eli Zaretskii > > Cc: 21699@debbugs.gnu.org > > > > So after fixing set-file-extended-attributes as you suggest, does the > > problem still happen for you? > > Actually, your suggested variant also returns nil for me. I need > something like this instead: > > (defun set-file-extended-attributes (filename attributes) > "Set extended attributes of file FILENAME to ATTRIBUTES. > > ATTRIBUTES must be an alist of file attributes as returned by > `file-extended-attributes'." > (let (result) > (dolist (elt attributes) > (let ((attr (car elt)) > (val (cdr elt))) > (cond ((eq attr 'acl) > (setq result (or result > (set-file-acl filename val)))) > ((eq attr 'selinux-context) > (setq result (or result > (set-file-selinux-context filename val))))))) > result)) I installed a slightly different variant of this (which always invokes the corresponding low-level primitive for each type of extended attributes, instead of skipping all those after the first success), to keep the original semantics. From debbugs-submit-bounces@debbugs.gnu.org Mon Oct 19 03:50:08 2015 Received: (at 21699) by debbugs.gnu.org; 19 Oct 2015 07:50:08 +0000 Received: from localhost ([127.0.0.1]:55687 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Zo5Cp-0006NO-8H for submit@debbugs.gnu.org; Mon, 19 Oct 2015 03:50:07 -0400 Received: from mail-ig0-f181.google.com ([209.85.213.181]:37507) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Zo5Cn-0006N7-CF for 21699@debbugs.gnu.org; Mon, 19 Oct 2015 03:50:06 -0400 Received: by igbhv6 with SMTP id hv6so51431917igb.0 for <21699@debbugs.gnu.org>; Mon, 19 Oct 2015 00:50:04 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=gUDCYpkjm3wStcGKRxUBaUcr/z3klt6bGLIHhb2tYs4=; b=QJfiRGe0lWmk6ac4oyo5wu+EG4kgDTohmd+5SqjTh8FU8EEfZc5sR+pogIx8b06y6J Q7ZnPZPmqN5XBOlLhRVu+ZQ0sFAjj2mAOW8f28zM5QFzA5rJVC3PvEE9JqibxAcZgerG +un09mwTC5q8+AJiEIIUBGmsLA+FI/9UEKgTkHjho8ocOGW/foLY+D8S4MU41uBxrU/L 5WlNhD82GALuAPVy18Y8MM8jSJW0ZqvcjuLSjUnUMjz0sgA4/0PoCkjMzNVdL78kocyF Fpu2ywJF9FntTzs7QmP9+VlySzVeoQHy7EUaF9o1om5POfOrJGyEf0kjaFVFChyFtfJo NfUg== X-Gm-Message-State: ALoCoQmxsvNb3Mn0B02bj3mJFlzl38UsiUhNXp7tJ2UyKcpywYtn2oQ3jsz9encwHZz07D6JDZjR MIME-Version: 1.0 X-Received: by 10.51.17.39 with SMTP id gb7mr16860000igd.56.1445241004674; Mon, 19 Oct 2015 00:50:04 -0700 (PDT) Received: by 10.79.28.211 with HTTP; Mon, 19 Oct 2015 00:50:04 -0700 (PDT) In-Reply-To: <83wpujgwr3.fsf@gnu.org> References: <831tcricrz.fsf@gnu.org> <83zizfgxnl.fsf@gnu.org> <83wpujgwr3.fsf@gnu.org> Date: Mon, 19 Oct 2015 03:50:04 -0400 Message-ID: Subject: Re: bug#21699: 24.5; Bug in backup-buffer-copy and/or set-file-extended-attributes etc [set-file-extended-attributes] From: Eli Barzilay To: Eli Zaretskii Content-Type: text/plain; charset=UTF-8 X-Spam-Score: 0.3 (/) X-Debbugs-Envelope-To: 21699 Cc: 21699@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.3 (/) [I'm working on the other things that you asked now...] On Mon, Oct 19, 2015 at 3:09 AM, Eli Zaretskii wrote: >> Date: Mon, 19 Oct 2015 09:50:06 +0300 >> From: Eli Zaretskii >> Cc: 21699@debbugs.gnu.org >> >> > Date: Mon, 19 Oct 2015 09:38:08 +0300 >> > From: Eli Zaretskii >> > Cc: 21699@debbugs.gnu.org >> > >> > So after fixing set-file-extended-attributes as you suggest, does the >> > problem still happen for you? >> >> Actually, your suggested variant also returns nil for me. Well, it would return nil since the result of `file-extended-attributes' would include (selinux-context nil nil nil nil) which sould make it try to use `set-file-selinux-context' and that returns nil. (That was my original point #3, addressed below.) >> I need something like this instead: >> [...2nd version...] This one would indeed return t for me, since it stops trying after the first t result from `set-file-acl'. > I installed a slightly different variant of this (which always invokes > the corresponding low-level primitive for each type of extended > attributes, instead of skipping all those after the first success), to > keep the original semantics. Well, you added this in the docstring: Value is t if the function succeeds in setting the attributes. which is a little vague -- I think that it would be better to say Value is t if the function succeeds in setting at least one of the attributes. *BUT* I doubt that this is a good idea, since on a system that supports both acl and selinux-context you probably want a t result to indicate that all of the extended settings worked. So I think that my original suggestion is better if `file-extended-attributes' doesn't produce values that are not supported. So ... moving on to that third problem, I fixed `file-extended-attributes' to do that: it doesn't include an `acl' value if `file-acl' returned nil, and doesn't include `selinux-context' if `file-selinux-context' returned (nil nil nil nil). I used this with my version of `set-file-extended-attributes' (which returns t only when all settings returned non-nil), and that resolved my backup problem. The code for the two functions, with updated docstrings, is below. ------------------------------------------------------------------------------- (defun file-extended-attributes (filename) "Return an alist of extended attributes of file FILENAME. Extended attributes are platform-specific metadata about the file, such as SELinux context, list of ACL entries, etc. Only supported metadata is included." (let ((attrs '()) x) (unless (equal nil (setq x (file-acl filename))) (push `(acl . ,x) attrs)) (unless (equal '(nil nil nil nil) (setq x (file-selinux-context filename))) (push `(selinux-context . ,x) attrs)) attrs)) (defun set-file-extended-attributes (filename attributes) "Set extended attributes of file FILENAME to ATTRIBUTES. ATTRIBUTES must be an alist of file attributes as returned by `file-extended-attributes'. Value is t if the function succeeds in setting all of the given attributes." (let ((result t)) (dolist (elt attributes) (let ((attr (car elt)) (val (cdr elt))) (unless (cond ((eq attr 'acl) (set-file-acl filename val)) ((eq attr 'selinux-context) (set-file-selinux-context filename val))) (setq result nil)))) result)) ------------------------------------------------------------------------------- -- ((x=>x(x))(x=>x(x))) Eli Barzilay: http://barzilay.org/ Maze is Life! From debbugs-submit-bounces@debbugs.gnu.org Mon Oct 19 03:57:16 2015 Received: (at 21699) by debbugs.gnu.org; 19 Oct 2015 07:57:16 +0000 Received: from localhost ([127.0.0.1]:55701 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Zo5Jk-0006XW-4R for submit@debbugs.gnu.org; Mon, 19 Oct 2015 03:57:16 -0400 Received: from mail-ig0-f174.google.com ([209.85.213.174]:34929) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Zo5Ji-0006XO-ED for 21699@debbugs.gnu.org; Mon, 19 Oct 2015 03:57:15 -0400 Received: by igbkq10 with SMTP id kq10so50919064igb.0 for <21699@debbugs.gnu.org>; Mon, 19 Oct 2015 00:57:13 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=hcCcdlco09UUW0a47Q2pzKSsdLv8wU98SlImzX72Uzk=; b=SnYqr7NESaAFEZrXZw/1Iy2hfBz9TJ07gvyLzWI7D1EUKoSBuQ/2Y77tTNUyK8DLoq yQc4Mx3MtAO6xppS5atsvjzeGrRozWZdk1MnJq8z69QuHdvPE4JMMFwAlN6yCu17mxEh 0rq2Z2/zphaA0E9iY+eUWogtqm6PqQb+pco3DLC/SK2q50X6FejLEyXpb1QZ8E9GglPE a66YuxWsbuBECb87YrCo+oMtuvpq3nPt76FhfT7r8+uK4aZAofvi2aWc2yiR7lC0R7Nq mDsUEpUyqiJVeRGykZB8iJ+08FP/U+NESg3k6Js93M2V1VI1ASy3rWMpaAQbFUTQcYn4 kejg== X-Gm-Message-State: ALoCoQkibEJGD+uMEXQOZEJhcm2J3fooaonHHNlDqMSWld91wk9ckQOBShV77EvzWYm61qdge6EP MIME-Version: 1.0 X-Received: by 10.50.22.5 with SMTP id z5mr5277218ige.49.1445241433714; Mon, 19 Oct 2015 00:57:13 -0700 (PDT) Received: by 10.79.28.211 with HTTP; Mon, 19 Oct 2015 00:57:13 -0700 (PDT) In-Reply-To: <838u6zigtr.fsf@gnu.org> References: <22051.8546.40000.221633@gargle.gargle.HOWL> <83wpuki2sf.fsf@gnu.org> <838u6zigtr.fsf@gnu.org> Date: Mon, 19 Oct 2015 03:57:13 -0400 Message-ID: Subject: Re: bug#21699: 24.5; Bug in backup-buffer-copy and/or set-file-extended-attributes etc From: Eli Barzilay To: Eli Zaretskii Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.3 (/) X-Debbugs-Envelope-To: 21699 Cc: 21699@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.3 (/) [I'm not sure that this is relevant, but since I had most of it written...] On Mon, Oct 19, 2015 at 1:10 AM, Eli Zaretskii wrote: >> Date: Sun, 18 Oct 2015 17:05:43 -0400 >> From: Eli Barzilay >> Cc: 21699@debbugs.gnu.org >> >> On Sun, Oct 18, 2015 at 12:01 PM, Eli Zaretskii wrote: >> > >> > Do you mean to say that backup-buffer-copy fails in your case? If so, >> > it means you have some customizations, or maybe the way your volume is >> > mounted causes backup-buffer-copy be called. It isn't normally called >> > in "emacs -Q" and with local files, AFAICT. >> > >> > Is that what happens in your case? >> > >> > Do you see the problem in "emacs -Q"? >> >> Yes, I do have customizations. Overall I'm not doing anything that >> should be done -- though I'm guessing that not many people get to that >> situation. The main thing in my setup is that backups are done by >> copying the file into a single directory for backups -- and in the >> problem case the backup is on a local windows directory when the >> original file is coming from a remote mount (on linux). > > Please do tell if the problem happens in "emacs -Q". We need to start > from same baseline which we understand. It might be better to also > show the results in "emacs -Q" when backup-by-copying is non-nil, but > with local files on a Windows volume. OK, I verified that it happens with -Q. The only customization I did was: (setq backup-directory-alist '(("." . "c:/eli/.backups/"))) where that directory exists and is on the NTFS filesystem. I then open an "l:/tmp/x" file, edit it, save, and that produces that error. That drive is mounted from a linux VM via samba. This happens regardless of the value of `backup-by-copying'. > Btw, what kind of volume is your Windows disk where you have the > backup directory? Is it NTFS, FAT32, something else? NTFS. > Also, I need the results of calling file-attributes and file-acl on > the file for which backup fails and on the backup directory. Here they are, running from "emacs -Q" too. I also included the results on the backup file itself (which *does* get created, as I said earlier): (file-attributes "l:/tmp/x") (nil 1 1000 513 (22052 36758 0 0) (22052 36761 0 0) (22052 36758 0 0) 21 "-rw-rw-rw-" t 0 (29879 . 49391)) (file-acl "l:/tmp/x") "O:S-1-5-21-255753047-2700399607-2208692068-1000G:S-1-22-2-1000D:P(A;= ;0x12019f;;;S-1-5-21-255753047-2700399607-2208692068-1000)(A;;FR;;;S-1-22-2= -1000)(A;;FR;;;WD)" (file-attributes "c:/eli/.backups") (t 1 1000 513 (22052 36737 0 0) (22052 36737 0 0) (21144 22619 0 0) 524288 "drwxrwxrwx" t (3584 0 . 63301) (58391 . 43832)) (file-acl "c:/eli/.backups") "O:S-1-5-21-1288650996-1850016226-2761200207-1000G:S-1-5-21-128865099= 6-1850016226-2761200207-513D:P(A;;FA;;;S-1-5-21-1288650996-1850016226-27612= 00207-1000)(A;;0x120080;;;S-1-5-21-1288650996-1850016226-2761200207-513)(A;= ;0x120080;;;WD)(A;OICIIOID;GA;;;BA)(A;ID;FA;;;SY)(A;OICIIOID;GA;;;SY)(A;OIC= IID;0x1200a9;;;BU)(A;ID;0x1301bf;;;AU)(A;OICIIOID;SDGXGWGR;;;AU)" (file-attributes "c:/eli/.backups/!drive_l!tmp!x~") (nil 1 1000 513 (22052 36737 0 0) (22052 36735 0 0) (21757 58044 0 0) 17 "-rw-rw-rw-" t (384512 1 . 20580) (58391 . 43832)) (file-acl "c:/eli/.backups/!drive_l!tmp!x~") "O:S-1-5-21-255753047-2700399607-2208692068-1000G:S-1-22-2-1000D:P(A;= ;0x12019f;;;S-1-5-21-255753047-2700399607-2208692068-1000)(A;;FR;;;S-1-22-2= -1000)(A;;FR;;;WD)" >> 2. The `set-file-extended-attributes' function always returns nil, which >> is a proper bug: >> - In `backup-buffer-copy' its return value is used as if it indicates >> whether it succeeded -- that's currently broken because it always >> returns nil. > > That's not a bug: set-file-extended-attributes is not supposed to > always return nil. When it succeeds, it returns t. It returns nil in > your case because it fails; the question is why. [...] (Moved to the other email.) >> 3. The third problem happens *if* the solution to #2 is to make it >> return a meaningful result. In that case, the problem I'll run into >> is that on windows my extended modes include >> >> (selinux nil nil nil nil) >> >> which I'm guessing is because there's no selinux support, but then >> `set-file-selinux-context' should not fail when getting a value of >> (nil nil nil nil). > > set-file-selinux-context is not supposed to be called on MS-Windows, > because SELinux APIs are not supported there. That's resolved with my suggested fix for `file-extended-attributes', making it drop the `selinux-context' when it's not supported. >> 4. The last problem of chmod-ing failing after setting the windows >> acl is probably better to defer after resolving the above. > > That's a big surprise: chmod is largely a no-op on Windows. If you > invoke set-file-modes exactly like backup-buffer-copy does, but from > the "M-:" prompt, what error does it report? I suspect that some of those ACL entries mean that my user is not allowed to change the file. In any case, the error that I got when I played with it is: Debugger entered--Lisp error: (file-error "Doing chmod" "permission denied" "c:/eli/.backups/!drive_l!lambda!tmp!x~") set-file-modes("c:/eli/.backups/!drive_l!lambda!tmp!x~" 438) eval((set-file-modes "c:/eli/.backups/!drive_l!lambda!tmp!x~" 438) nil) > Are you sure backup-buffer-copy even copies the file to the backup > directory? IOW, does the call to copy-file inside backup-buffer-copy > work? If it does not, that would explain why both > set-file-extended-attributes and set-file-modes fail afterwards. So > perhaps manually running the code of backup-buffer-copy step by step > with a file on your Linux volume would show where the failure starts. That should hopefully be clear now too, but yes -- the way it'd work is * create the backup copy, * set the acl (which works fine), * think that it failed, and then resorted to the fallback file. --=20 ((x=3D>x(x))(x=3D>x(x))) Eli Barzilay= : http://barzilay.org/ Maze is Life! From debbugs-submit-bounces@debbugs.gnu.org Mon Oct 19 04:04:26 2015 Received: (at 21699) by debbugs.gnu.org; 19 Oct 2015 08:04:27 +0000 Received: from localhost ([127.0.0.1]:55707 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Zo5Qg-0006ii-F0 for submit@debbugs.gnu.org; Mon, 19 Oct 2015 04:04:26 -0400 Received: from mtaout22.012.net.il ([80.179.55.172]:60638) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Zo5Qd-0006iX-92 for 21699@debbugs.gnu.org; Mon, 19 Oct 2015 04:04:24 -0400 Received: from conversion-daemon.a-mtaout22.012.net.il by a-mtaout22.012.net.il (HyperSendmail v2007.08) id <0NWG00900JQFKY00@a-mtaout22.012.net.il> for 21699@debbugs.gnu.org; Mon, 19 Oct 2015 11:04:21 +0300 (IDT) Received: from HOME-C4E4A596F7 ([84.94.185.246]) by a-mtaout22.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NWG009PJJR8DN40@a-mtaout22.012.net.il>; Mon, 19 Oct 2015 11:04:21 +0300 (IDT) Date: Mon, 19 Oct 2015 11:04:23 +0300 From: Eli Zaretskii Subject: Re: bug#21699: 24.5; Bug in backup-buffer-copy and/or set-file-extended-attributes etc [set-file-extended-attributes] In-reply-to: X-012-Sender: halo1@inter.net.il To: Eli Barzilay Message-id: <83si57gu7s.fsf@gnu.org> References: <831tcricrz.fsf@gnu.org> <83zizfgxnl.fsf@gnu.org> <83wpujgwr3.fsf@gnu.org> X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 21699 Cc: 21699@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) > Date: Mon, 19 Oct 2015 03:50:04 -0400 > From: Eli Barzilay > Cc: 21699@debbugs.gnu.org > > >> Actually, your suggested variant also returns nil for me. > > Well, it would return nil since the result of `file-extended-attributes' > would include (selinux-context nil nil nil nil) It always does, AFAICT. > > I installed a slightly different variant of this (which always invokes > > the corresponding low-level primitive for each type of extended > > attributes, instead of skipping all those after the first success), to > > keep the original semantics. > > Well, you added this in the docstring: > > Value is t if the function succeeds in setting the attributes. > > which is a little vague -- I think that it would be better to say > > Value is t if the function succeeds in setting at least one of the > attributes. We don't have enough information from the low-level APIs to tell that. So yes, it's slightly vague, but intentionally so. > *BUT* I doubt that this is a good idea, since on a system that supports > both acl and selinux-context you probably want a t result to indicate > that all of the extended settings worked. I don't think this is true. Many (maybe most) systems support either ACLs or SELinux, and for them the function will incorrectly return nil. A better way might be to have a test of "null" attributes, and avoid calling the low-level APIs when the attributes are "null". A separate issue, I think. From debbugs-submit-bounces@debbugs.gnu.org Mon Oct 19 04:23:38 2015 Received: (at 21699) by debbugs.gnu.org; 19 Oct 2015 08:23:38 +0000 Received: from localhost ([127.0.0.1]:55712 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Zo5jF-0007AQ-Ga for submit@debbugs.gnu.org; Mon, 19 Oct 2015 04:23:37 -0400 Received: from mtaout22.012.net.il ([80.179.55.172]:65028) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Zo5jD-0007AG-8y for 21699@debbugs.gnu.org; Mon, 19 Oct 2015 04:23:36 -0400 Received: from conversion-daemon.a-mtaout22.012.net.il by a-mtaout22.012.net.il (HyperSendmail v2007.08) id <0NWG00900KCVOK00@a-mtaout22.012.net.il> for 21699@debbugs.gnu.org; Mon, 19 Oct 2015 11:23:34 +0300 (IDT) Received: from HOME-C4E4A596F7 ([84.94.185.246]) by a-mtaout22.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NWG009GIKN9JV40@a-mtaout22.012.net.il>; Mon, 19 Oct 2015 11:23:34 +0300 (IDT) Date: Mon, 19 Oct 2015 11:23:36 +0300 From: Eli Zaretskii Subject: Re: bug#21699: 24.5; Bug in backup-buffer-copy and/or set-file-extended-attributes etc In-reply-to: X-012-Sender: halo1@inter.net.il To: Eli Barzilay Message-id: <83r3krgtbr.fsf@gnu.org> References: <22051.8546.40000.221633@gargle.gargle.HOWL> <83wpuki2sf.fsf@gnu.org> <838u6zigtr.fsf@gnu.org> X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 21699 Cc: 21699@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) > Date: Mon, 19 Oct 2015 03:57:13 -0400 > From: Eli Barzilay > Cc: 21699@debbugs.gnu.org > > > Also, I need the results of calling file-attributes and file-acl on > > the file for which backup fails and on the backup directory. > > Here they are, running from "emacs -Q" too. I also included the results > on the backup file itself (which *does* get created, as I said earlier): > > (file-attributes "l:/tmp/x") > (nil 1 1000 513 (22052 36758 0 0) (22052 36761 0 0) (22052 36758 > 0 0) 21 "-rw-rw-rw-" t 0 (29879 . 49391)) > (file-acl "l:/tmp/x") > "O:S-1-5-21-255753047-2700399607-2208692068-1000G:S-1-22-2-1000D:P(A;;0x12019f;;;S-1-5-21-255753047-2700399607-2208692068-1000)(A;;FR;;;S-1-22-2-1000)(A;;FR;;;WD)" > > (file-attributes "c:/eli/.backups") > (t 1 1000 513 (22052 36737 0 0) (22052 36737 0 0) (21144 22619 0 > 0) 524288 "drwxrwxrwx" t (3584 0 . 63301) (58391 . 43832)) > (file-acl "c:/eli/.backups") > "O:S-1-5-21-1288650996-1850016226-2761200207-1000G:S-1-5-21-1288650996-1850016226-2761200207-513D:P(A;;FA;;;S-1-5-21-1288650996-1850016226-2761200207-1000)(A;;0x120080;;;S-1-5-21-1288650996-1850016226-2761200207-513)(A;;0x120080;;;WD)(A;OICIIOID;GA;;;BA)(A;ID;FA;;;SY)(A;OICIIOID;GA;;;SY)(A;OICIID;0x1200a9;;;BU)(A;ID;0x1301bf;;;AU)(A;OICIIOID;SDGXGWGR;;;AU)" > > (file-attributes "c:/eli/.backups/!drive_l!tmp!x~") > (nil 1 1000 513 (22052 36737 0 0) (22052 36735 0 0) (21757 58044 > 0 0) 17 "-rw-rw-rw-" t (384512 1 . 20580) (58391 . 43832)) > (file-acl "c:/eli/.backups/!drive_l!tmp!x~") > "O:S-1-5-21-255753047-2700399607-2208692068-1000G:S-1-22-2-1000D:P(A;;0x12019f;;;S-1-5-21-255753047-2700399607-2208692068-1000)(A;;FR;;;S-1-22-2-1000)(A;;FR;;;WD)" AFAIU, this means you don't have full access ("FA") to the file you are editing, and I guess that's why chmod fails. If so, there's not much we can do about that. However, with set-file-extended-attributes fixed, backing up works again for you, is that right? > >> 4. The last problem of chmod-ing failing after setting the windows > >> acl is probably better to defer after resolving the above. > > > > That's a big surprise: chmod is largely a no-op on Windows. If you > > invoke set-file-modes exactly like backup-buffer-copy does, but from > > the "M-:" prompt, what error does it report? > > I suspect that some of those ACL entries mean that my user is not > allowed to change the file. In any case, the error that I got when I > played with it is: > > Debugger entered--Lisp error: (file-error "Doing chmod" "permission > denied" "c:/eli/.backups/!drive_l!lambda!tmp!x~") > set-file-modes("c:/eli/.backups/!drive_l!lambda!tmp!x~" 438) > eval((set-file-modes "c:/eli/.backups/!drive_l!lambda!tmp!x~" 438) nil) Yes, I think your suspicion is correct. (In general, I'd suggest to take ownership, from the Windows side, on all of the files on that Linux volume you are using from Windows. IME, this avoids many problems with access denial from the Windows side.) From debbugs-submit-bounces@debbugs.gnu.org Mon Oct 19 05:03:23 2015 Received: (at 21699) by debbugs.gnu.org; 19 Oct 2015 09:03:23 +0000 Received: from localhost ([127.0.0.1]:55719 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Zo6Lj-00084F-A7 for submit@debbugs.gnu.org; Mon, 19 Oct 2015 05:03:23 -0400 Received: from mail-ig0-f181.google.com ([209.85.213.181]:38135) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Zo6Lg-000845-1M for 21699@debbugs.gnu.org; Mon, 19 Oct 2015 05:03:21 -0400 Received: by igbdj2 with SMTP id dj2so52309005igb.1 for <21699@debbugs.gnu.org>; Mon, 19 Oct 2015 02:03:19 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=AMZ5tgRw2RzjbbD8bvqggYIEfd2TMv877uNTYtTui/g=; b=kGZ2VPRSxkBD9n25rFd+ePM8HrtfAI2ylrFOBl8kctbB8HBDSUN/tJQ33Pxo3ePtbU ZSlZQ9i6bzIXbKkSbwQHdVENZ5g2YDapV2IcJVwnkRh31rogMbYWwS2HPWcvLU3ik/nG DnhPSzJcX5l+by7pXQWeQ64Szh43QNVZTWPGFyVnISx7fjyDRtek99IGra9Re6VSa1yz 9kBR9yBJOMiuzWmZlu8mDHt1a3mTO6/6SnrkXCS6gJezvdJ9mrpsrsb30osfJ5jlKZX/ NAxCOb3+kUkynL96E3s+sgvkR9MKowU3+KS1PvFbXdeFLKJs1sQSl1ty/anwMzzvqSPq eoig== X-Gm-Message-State: ALoCoQnday29F+chu++se8ZhgxfBaD2ZMGDqbO47XaoR9SYoqgIhlgq/j9lmFsmU7rfYUJJi4env MIME-Version: 1.0 X-Received: by 10.50.1.83 with SMTP id 19mr6416068igk.56.1445245399340; Mon, 19 Oct 2015 02:03:19 -0700 (PDT) Received: by 10.79.28.211 with HTTP; Mon, 19 Oct 2015 02:03:19 -0700 (PDT) In-Reply-To: <83r3krgtbr.fsf@gnu.org> References: <22051.8546.40000.221633@gargle.gargle.HOWL> <83wpuki2sf.fsf@gnu.org> <838u6zigtr.fsf@gnu.org> <83r3krgtbr.fsf@gnu.org> Date: Mon, 19 Oct 2015 05:03:19 -0400 Message-ID: Subject: Re: bug#21699: 24.5; Bug in backup-buffer-copy and/or set-file-extended-attributes etc From: Eli Barzilay To: Eli Zaretskii Content-Type: text/plain; charset=UTF-8 X-Spam-Score: 0.3 (/) X-Debbugs-Envelope-To: 21699 Cc: 21699@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.3 (/) On Mon, Oct 19, 2015 at 4:23 AM, Eli Zaretskii wrote: > > AFAIU, this means you don't have full access ("FA") to the file you > are editing, and I guess that's why chmod fails. If so, there's not > much we can do about that. > > However, with set-file-extended-attributes fixed, backing up works > again for you, is that right? Yes. (On both.) >> I suspect that some of those ACL entries mean that my user is not >> allowed to change the file. In any case, the error that I got when I >> played with it is: >> >> Debugger entered--Lisp error: (file-error "Doing chmod" "permission >> denied" "c:/eli/.backups/!drive_l!lambda!tmp!x~") >> set-file-modes("c:/eli/.backups/!drive_l!lambda!tmp!x~" 438) >> eval((set-file-modes "c:/eli/.backups/!drive_l!lambda!tmp!x~" 438) nil) > > Yes, I think your suspicion is correct. (In general, I'd suggest to > take ownership, from the Windows side, on all of the files on that > Linux volume you are using from Windows. IME, this avoids many > problems with access denial from the Windows side.) Yeah, I didn't get to deal with that yet, and maybe will never since this is a Win7 machine, and I think that on 10 these things changed. -- ((x=>x(x))(x=>x(x))) Eli Barzilay: http://barzilay.org/ Maze is Life! From debbugs-submit-bounces@debbugs.gnu.org Mon Oct 19 05:09:42 2015 Received: (at 21699) by debbugs.gnu.org; 19 Oct 2015 09:09:42 +0000 Received: from localhost ([127.0.0.1]:55723 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Zo6Rq-0008Cd-6D for submit@debbugs.gnu.org; Mon, 19 Oct 2015 05:09:42 -0400 Received: from mtaout29.012.net.il ([80.179.55.185]:54288) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Zo6Rn-0008CT-6x for 21699@debbugs.gnu.org; Mon, 19 Oct 2015 05:09:40 -0400 Received: from conversion-daemon.mtaout29.012.net.il by mtaout29.012.net.il (HyperSendmail v2007.08) id <0NWG00E00MPIXV00@mtaout29.012.net.il> for 21699@debbugs.gnu.org; Mon, 19 Oct 2015 12:09:00 +0300 (IDT) Received: from HOME-C4E4A596F7 ([84.94.185.246]) by mtaout29.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NWG009WEMQZ8D50@mtaout29.012.net.il>; Mon, 19 Oct 2015 12:09:00 +0300 (IDT) Date: Mon, 19 Oct 2015 12:09:39 +0300 From: Eli Zaretskii Subject: Re: bug#21699: 24.5; Bug in backup-buffer-copy and/or set-file-extended-attributes etc In-reply-to: X-012-Sender: halo1@inter.net.il To: Eli Barzilay Message-id: <83mvvfgr70.fsf@gnu.org> References: <22051.8546.40000.221633@gargle.gargle.HOWL> <83wpuki2sf.fsf@gnu.org> <838u6zigtr.fsf@gnu.org> <83r3krgtbr.fsf@gnu.org> X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 21699 Cc: 21699@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) > Date: Mon, 19 Oct 2015 05:03:19 -0400 > From: Eli Barzilay > Cc: 21699@debbugs.gnu.org > > On Mon, Oct 19, 2015 at 4:23 AM, Eli Zaretskii wrote: > > > > AFAIU, this means you don't have full access ("FA") to the file you > > are editing, and I guess that's why chmod fails. If so, there's not > > much we can do about that. > > > > However, with set-file-extended-attributes fixed, backing up works > > again for you, is that right? > > Yes. (On both.) OK, thanks. Can we close this bug? > >> I suspect that some of those ACL entries mean that my user is not > >> allowed to change the file. In any case, the error that I got when I > >> played with it is: > >> > >> Debugger entered--Lisp error: (file-error "Doing chmod" "permission > >> denied" "c:/eli/.backups/!drive_l!lambda!tmp!x~") > >> set-file-modes("c:/eli/.backups/!drive_l!lambda!tmp!x~" 438) > >> eval((set-file-modes "c:/eli/.backups/!drive_l!lambda!tmp!x~" 438) nil) > > > > Yes, I think your suspicion is correct. (In general, I'd suggest to > > take ownership, from the Windows side, on all of the files on that > > Linux volume you are using from Windows. IME, this avoids many > > problems with access denial from the Windows side.) > > Yeah, I didn't get to deal with that yet, and maybe will never since > this is a Win7 machine, and I think that on 10 these things changed. I don't have a Windows 10 system nearby to see if anything's changed in that regard. Any pointers? Thanks. From debbugs-submit-bounces@debbugs.gnu.org Mon Oct 19 05:11:01 2015 Received: (at 21699) by debbugs.gnu.org; 19 Oct 2015 09:11:01 +0000 Received: from localhost ([127.0.0.1]:55727 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Zo6T6-0008Ea-O7 for submit@debbugs.gnu.org; Mon, 19 Oct 2015 05:11:01 -0400 Received: from mail-io0-f170.google.com ([209.85.223.170]:36787) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Zo6T5-0008ET-El for 21699@debbugs.gnu.org; Mon, 19 Oct 2015 05:11:00 -0400 Received: by ioll68 with SMTP id l68so22438958iol.3 for <21699@debbugs.gnu.org>; Mon, 19 Oct 2015 02:10:59 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=R3wNW42VoYoM2k38j3yerID9Y32eDUP+g6ZhhOZAt20=; b=AiSesz9ZjRz+23BRx8rUk4U+Jvk2qPTSxfPma8jsgWHQYAKlLaGvz6HUQy5Hweum0h OWdQM7b1NrR1SpFu18IepD5FUfhjNja15T5SRwSN6tm4bWvU+76fFqpO9K3aPAjSajeG SsRWQEwuNUQjx9zYT/FohoDNqAX+zCjNRxtRs3WVp/cekkrhyk52rYd0xKC1dM3EuDWK qmvUFTuuu5cmPbAfWQujwkO5lcVUIAdLUcNu1e+HZnssW8VE24daemtvdCJ1L2J+hjTB eW0iFDwpEqE3qO3QSpZ/mAvmNHKTI851FfmZ4MT3f2q9FPkU6xOPlowMlBfTZPM7GuqN TiOA== X-Gm-Message-State: ALoCoQks8aoIKyKs52I6xDi062RnYFBENYBBftcT60sYTnZqMe8vSHzfV4A8FTKMaPmYOKOzKzKD MIME-Version: 1.0 X-Received: by 10.107.137.66 with SMTP id l63mr14833580iod.112.1445245859019; Mon, 19 Oct 2015 02:10:59 -0700 (PDT) Received: by 10.79.28.211 with HTTP; Mon, 19 Oct 2015 02:10:58 -0700 (PDT) In-Reply-To: <83si57gu7s.fsf@gnu.org> References: <831tcricrz.fsf@gnu.org> <83zizfgxnl.fsf@gnu.org> <83wpujgwr3.fsf@gnu.org> <83si57gu7s.fsf@gnu.org> Date: Mon, 19 Oct 2015 05:10:58 -0400 Message-ID: Subject: Re: bug#21699: 24.5; Bug in backup-buffer-copy and/or set-file-extended-attributes etc [set-file-extended-attributes] From: Eli Barzilay To: Eli Zaretskii Content-Type: text/plain; charset=UTF-8 X-Spam-Score: 0.3 (/) X-Debbugs-Envelope-To: 21699 Cc: 21699@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.3 (/) On Mon, Oct 19, 2015 at 4:04 AM, Eli Zaretskii wrote: >> Date: Mon, 19 Oct 2015 03:50:04 -0400 >> From: Eli Barzilay >> Cc: 21699@debbugs.gnu.org >> >> *BUT* I doubt that this is a good idea, since on a system that >> supports both acl and selinux-context you probably want a t result to >> indicate that all of the extended settings worked. > > I don't think this is true. Many (maybe most) systems support either > ACLs or SELinux, and for them the function will incorrectly return > nil. > > A better way might be to have a test of "null" attributes, and avoid > calling the low-level APIs when the attributes are "null". A separate > issue, I think. Did you have a look at my `file-extended-attributes' fix? It does just that: when the low-level functions return "null" (four nils in the selinux case), then they won't get included in the result. This frees `set-file-extended-attributes' to require that all settings succeed. And I think that there's one case where things would fail with your fix: a linux machine that has selinux disabled will have this as the extended attributes: ((acl . nil) (selinux-context . (nil nil nil nil))) and your version of `set-file-extended-attributes' would fail when both of these fail. With my fix, `file-extended-attributes' would just return nil in that case, and `set-file-extended-attributes' will succeed trivially. -- ((x=>x(x))(x=>x(x))) Eli Barzilay: http://barzilay.org/ Maze is Life! From debbugs-submit-bounces@debbugs.gnu.org Mon Oct 19 05:14:10 2015 Received: (at 21699) by debbugs.gnu.org; 19 Oct 2015 09:14:10 +0000 Received: from localhost ([127.0.0.1]:55733 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Zo6W9-0008JT-D6 for submit@debbugs.gnu.org; Mon, 19 Oct 2015 05:14:09 -0400 Received: from mail-ig0-f182.google.com ([209.85.213.182]:34455) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Zo6W7-0008JK-7e for 21699@debbugs.gnu.org; Mon, 19 Oct 2015 05:14:07 -0400 Received: by igbni9 with SMTP id ni9so50182753igb.1 for <21699@debbugs.gnu.org>; Mon, 19 Oct 2015 02:14:06 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=r7+q7xz34F4mphShVwymS/RTbEYHlUmgQheA1FhhRks=; b=RsKzUA1vdCOT6qU5Gnj344Fz3OK4yz816178kXXlCecJSBMEmGieMy4svRh1fn/moB Ys85CWzQbr7167cqNKDI7PKLsbe5gDz6VbGis2RaAgSJEXlZQ0a6FdqOMhbbFDFRbCOY IkCjDIqHbawHZ9UdTxhKCaUX909s4AlFnuCdh3laf87xSe0AFAKakLAbd/JokY7cZ4Ou UAe5hO+SCCR0S8ebc2gIlj5GpSQmct2W5bQ6mdeA3XWSJ+nXObqyN6PHVUA+3heUPTAR xdgNo7Wxx+KR9vxZ9NGZxPyXO1t3tUUrTU8I8CgbfMM2HBLj1yMM6UNMfVZmWIbK7raD vkjg== X-Gm-Message-State: ALoCoQkU930pvLBBkTB9oF16rwzhB9uiZzKDsLxhKTBOtuw1o/zO9HfkBfvvwLA0TGi5ZQbbqYTl MIME-Version: 1.0 X-Received: by 10.50.137.97 with SMTP id qh1mr18395197igb.60.1445246046841; Mon, 19 Oct 2015 02:14:06 -0700 (PDT) Received: by 10.79.28.211 with HTTP; Mon, 19 Oct 2015 02:14:06 -0700 (PDT) In-Reply-To: <83mvvfgr70.fsf@gnu.org> References: <22051.8546.40000.221633@gargle.gargle.HOWL> <83wpuki2sf.fsf@gnu.org> <838u6zigtr.fsf@gnu.org> <83r3krgtbr.fsf@gnu.org> <83mvvfgr70.fsf@gnu.org> Date: Mon, 19 Oct 2015 05:14:06 -0400 Message-ID: Subject: Re: bug#21699: 24.5; Bug in backup-buffer-copy and/or set-file-extended-attributes etc From: Eli Barzilay To: Eli Zaretskii Content-Type: text/plain; charset=UTF-8 X-Spam-Score: 0.3 (/) X-Debbugs-Envelope-To: 21699 Cc: 21699@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.3 (/) On Mon, Oct 19, 2015 at 5:09 AM, Eli Zaretskii wrote: >> Date: Mon, 19 Oct 2015 05:03:19 -0400 >> From: Eli Barzilay >> Cc: 21699@debbugs.gnu.org >> >> On Mon, Oct 19, 2015 at 4:23 AM, Eli Zaretskii wrote: >> > >> > AFAIU, this means you don't have full access ("FA") to the file you >> > are editing, and I guess that's why chmod fails. If so, there's not >> > much we can do about that. >> > >> > However, with set-file-extended-attributes fixed, backing up works >> > again for you, is that right? >> >> Yes. (On both.) > > OK, thanks. Can we close this bug? There's the issue of the `file-extended-attributes' fix (in the other thread), and I think a possible leftover bad case. >> >> I suspect that some of those ACL entries mean that my user is not >> >> allowed to change the file. In any case, the error that I got when I >> >> played with it is: >> >> >> >> Debugger entered--Lisp error: (file-error "Doing chmod" "permission >> >> denied" "c:/eli/.backups/!drive_l!lambda!tmp!x~") >> >> set-file-modes("c:/eli/.backups/!drive_l!lambda!tmp!x~" 438) >> >> eval((set-file-modes "c:/eli/.backups/!drive_l!lambda!tmp!x~" 438) nil) >> > >> > Yes, I think your suspicion is correct. (In general, I'd suggest to >> > take ownership, from the Windows side, on all of the files on that >> > Linux volume you are using from Windows. IME, this avoids many >> > problems with access denial from the Windows side.) >> >> Yeah, I didn't get to deal with that yet, and maybe will never since >> this is a Win7 machine, and I think that on 10 these things changed. > > I don't have a Windows 10 system nearby to see if anything's changed > in that regard. Any pointers? I didn't try to verify it yet, but I vaguely remember somewhere that talked about making things less restricted by default, resolving the problem of putting files on an external HD and changing the owner when you want to use the drive in a different machine. (Which is what I do now, with a drive that gets populated on the win7 machine.) -- ((x=>x(x))(x=>x(x))) Eli Barzilay: http://barzilay.org/ Maze is Life! From debbugs-submit-bounces@debbugs.gnu.org Mon Oct 19 05:22:12 2015 Received: (at 21699) by debbugs.gnu.org; 19 Oct 2015 09:22:12 +0000 Received: from localhost ([127.0.0.1]:55740 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Zo6dv-0008Vh-T8 for submit@debbugs.gnu.org; Mon, 19 Oct 2015 05:22:12 -0400 Received: from mtaout21.012.net.il ([80.179.55.169]:64437) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Zo6dt-0008VO-QO for 21699@debbugs.gnu.org; Mon, 19 Oct 2015 05:22:10 -0400 Received: from conversion-daemon.a-mtaout21.012.net.il by a-mtaout21.012.net.il (HyperSendmail v2007.08) id <0NWG00300N9X5800@a-mtaout21.012.net.il> for 21699@debbugs.gnu.org; Mon, 19 Oct 2015 12:22:08 +0300 (IDT) Received: from HOME-C4E4A596F7 ([84.94.185.246]) by a-mtaout21.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NWG003U0NCV0K50@a-mtaout21.012.net.il>; Mon, 19 Oct 2015 12:22:08 +0300 (IDT) Date: Mon, 19 Oct 2015 12:22:10 +0300 From: Eli Zaretskii Subject: Re: bug#21699: 24.5; Bug in backup-buffer-copy and/or set-file-extended-attributes etc [set-file-extended-attributes] In-reply-to: X-012-Sender: halo1@inter.net.il To: Eli Barzilay Message-id: <83k2qjgqm5.fsf@gnu.org> References: <831tcricrz.fsf@gnu.org> <83zizfgxnl.fsf@gnu.org> <83wpujgwr3.fsf@gnu.org> <83si57gu7s.fsf@gnu.org> X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 21699 Cc: 21699@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) > Date: Mon, 19 Oct 2015 05:10:58 -0400 > From: Eli Barzilay > Cc: 21699@debbugs.gnu.org > > On Mon, Oct 19, 2015 at 4:04 AM, Eli Zaretskii wrote: > >> Date: Mon, 19 Oct 2015 03:50:04 -0400 > >> From: Eli Barzilay > >> Cc: 21699@debbugs.gnu.org > >> > >> *BUT* I doubt that this is a good idea, since on a system that > >> supports both acl and selinux-context you probably want a t result to > >> indicate that all of the extended settings worked. > > > > I don't think this is true. Many (maybe most) systems support either > > ACLs or SELinux, and for them the function will incorrectly return > > nil. > > > > A better way might be to have a test of "null" attributes, and avoid > > calling the low-level APIs when the attributes are "null". A separate > > issue, I think. > > Did you have a look at my `file-extended-attributes' fix? It does just > that: when the low-level functions return "null" (four nils in the > selinux case), then they won't get included in the result. This frees > `set-file-extended-attributes' to require that all settings succeed. Yes, I've seen that. But I'm not sure that we want such a change, because it loses some information: namely, that the failed interfaces did fail, or, equivalently, that information about the other kinds of attributes is not available. I don't know if this is important, but it does change the semantics of an interface that was already released. So I preferred a fix that didn't involve such changes. > And I think that there's one case where things would fail with your fix: > a linux machine that has selinux disabled will have this as the extended > attributes: > > ((acl . nil) (selinux-context . (nil nil nil nil))) > > and your version of `set-file-extended-attributes' would fail when both > of these fail. You mean, a GNU/Linux machine that supports neither ACLs nor SELinux, I suppose. Do such machines exist, and if so, are they popular? > With my fix, `file-extended-attributes' would just return nil in > that case, and `set-file-extended-attributes' will succeed > trivially. Why should set-file-extended-attributes succeed in this case? It didn't set any extended attributes, right? And if neither ACLs nor SELinux is supported, we should definitely fall back on chmod for the backup files, shouldn't we? From debbugs-submit-bounces@debbugs.gnu.org Mon Oct 19 05:47:40 2015 Received: (at 21699) by debbugs.gnu.org; 19 Oct 2015 09:47:40 +0000 Received: from localhost ([127.0.0.1]:55756 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Zo72Z-0000f4-VV for submit@debbugs.gnu.org; Mon, 19 Oct 2015 05:47:40 -0400 Received: from mail-io0-f172.google.com ([209.85.223.172]:34111) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Zo72X-0000ev-Km for 21699@debbugs.gnu.org; Mon, 19 Oct 2015 05:47:38 -0400 Received: by iow1 with SMTP id 1so183063743iow.1 for <21699@debbugs.gnu.org>; Mon, 19 Oct 2015 02:47:37 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=KuLoY5CywMgscQ9Os1ky+fdeWiyU7Y2vEW0u/rjhafM=; b=gOgi4fCoKUm/voo+uTeqFjGuplXlVA81bScHPkxDYIk6r9qtVwVR782pUh4Rk97W6H 51ZpqvgWJJnsRBSITQoauE2TOYNBIdQTuVG4CiGYEuSJ1kj7zN4+Aq8B0zJCeE4TW1Ww GKfkFa9hTKv4trJUtxtraGmu2fN/TdC6E4VXKa1o2FhAIhXAaidNzRX/lPxdS5LIAYO9 wCpDL+js+Ji2825rOAS01FjjVTwEVZRHiv3qpAS2H0eTOmsO96VfSgTktJ5Fl+KSNo2G zz0Wcb5fTHf9L9lgaUSuLQTDnjXfdC1VMDQYgKaRrZh7nua4iZ6cWIe/3fSBLTbff6tN kCxQ== X-Gm-Message-State: ALoCoQnNtz9+9hRHUCkcFsiGGge1KoOzTmrFptEIWLHIPTxAwAvSpuKfU3YLynuOlTIVNixcaNKD MIME-Version: 1.0 X-Received: by 10.107.137.66 with SMTP id l63mr14963539iod.112.1445248057031; Mon, 19 Oct 2015 02:47:37 -0700 (PDT) Received: by 10.79.28.211 with HTTP; Mon, 19 Oct 2015 02:47:36 -0700 (PDT) In-Reply-To: <83k2qjgqm5.fsf@gnu.org> References: <831tcricrz.fsf@gnu.org> <83zizfgxnl.fsf@gnu.org> <83wpujgwr3.fsf@gnu.org> <83si57gu7s.fsf@gnu.org> <83k2qjgqm5.fsf@gnu.org> Date: Mon, 19 Oct 2015 05:47:36 -0400 Message-ID: Subject: Re: bug#21699: 24.5; Bug in backup-buffer-copy and/or set-file-extended-attributes etc [set-file-extended-attributes] From: Eli Barzilay To: Eli Zaretskii Content-Type: text/plain; charset=UTF-8 X-Spam-Score: 0.3 (/) X-Debbugs-Envelope-To: 21699 Cc: 21699@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.3 (/) On Mon, Oct 19, 2015 at 5:22 AM, Eli Zaretskii wrote: >> Date: Mon, 19 Oct 2015 05:10:58 -0400 >> From: Eli Barzilay >> Cc: 21699@debbugs.gnu.org >> >> On Mon, Oct 19, 2015 at 4:04 AM, Eli Zaretskii wrote: >> >> Date: Mon, 19 Oct 2015 03:50:04 -0400 >> >> From: Eli Barzilay >> >> Cc: 21699@debbugs.gnu.org >> >> >> >> *BUT* I doubt that this is a good idea, since on a system that >> >> supports both acl and selinux-context you probably want a t result to >> >> indicate that all of the extended settings worked. >> > >> > I don't think this is true. Many (maybe most) systems support either >> > ACLs or SELinux, and for them the function will incorrectly return >> > nil. >> > >> > A better way might be to have a test of "null" attributes, and avoid >> > calling the low-level APIs when the attributes are "null". A separate >> > issue, I think. >> >> Did you have a look at my `file-extended-attributes' fix? It does just >> that: when the low-level functions return "null" (four nils in the >> selinux case), then they won't get included in the result. This frees >> `set-file-extended-attributes' to require that all settings succeed. > > Yes, I've seen that. But I'm not sure that we want such a change, > because it loses some information: namely, that the failed interfaces > did fail, or, equivalently, that information about the other kinds of > attributes is not available. OK. > I don't know if this is important, but it does change the semantics of > an interface that was already released. So I preferred a fix that > didn't involve such changes. OK, here's a version that does the decision in `set-file-extended-attributes', making it succeed if all of the given attributes were set but ignoring the "null" values. (Again, I verified that it works in my case.) ------------------------------------------------------------------------------- (defun set-file-extended-attributes (filename attributes) "Set extended attributes of file FILENAME to ATTRIBUTES. ATTRIBUTES must be an alist of file attributes as returned by `file-extended-attributes'. Value is t if the function succeeds in setting all of the given attributes excluding ones that indicate \"no information\"." (let ((result t)) (dolist (elt attributes) (let ((attr (car elt)) (val (cdr elt))) (unless (cond ((eq attr 'acl) (or (equal val nil) (set-file-acl filename val))) ((eq attr 'selinux-context) (or (equal val '(nil nil nil nil)) (set-file-selinux-context filename val)))) (setq result nil)))) result)) ------------------------------------------------------------------------------- >> And I think that there's one case where things would fail with your fix: >> a linux machine that has selinux disabled will have this as the extended >> attributes: >> >> ((acl . nil) (selinux-context . (nil nil nil nil))) >> >> and your version of `set-file-extended-attributes' would fail when both >> of these fail. > > You mean, a GNU/Linux machine that supports neither ACLs nor SELinux, > I suppose. Do such machines exist, and if so, are they popular? I think that there are still administrators of servers that disable selinux since dealing with it can be a PITA. It's at least something that was popular a few years ago, so I'm guessing that such setups are still used. Also, some quick web grepping got me to https://wiki.debian.org/SELinux which says The Debian packaged Linux kernels have SELinux support compiled in, but disabled by default. ... Please note that SELinux is a Linux-specific feature and Debian packages shouldn't assume it is present >> With my fix, `file-extended-attributes' would just return nil in >> that case, and `set-file-extended-attributes' will succeed >> trivially. > > Why should set-file-extended-attributes succeed in this case? It > didn't set any extended attributes, right? Well, it did set all of the specified attributes, since there were none of them. My new fix above will succeed in this case because it will ignore all of them. > And if neither ACLs nor SELinux is supported, we should definitely > fall back on chmod for the backup files, shouldn't we? But chmod is not done on backup files other than copy the original bits to the backup. (The failure I had with that was for the fallback file.) -- ((x=>x(x))(x=>x(x))) Eli Barzilay: http://barzilay.org/ Maze is Life! From debbugs-submit-bounces@debbugs.gnu.org Mon Oct 19 06:15:18 2015 Received: (at 21699) by debbugs.gnu.org; 19 Oct 2015 10:15:18 +0000 Received: from localhost ([127.0.0.1]:55781 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Zo7TJ-0001Ix-EA for submit@debbugs.gnu.org; Mon, 19 Oct 2015 06:15:18 -0400 Received: from mtaout27.012.net.il ([80.179.55.183]:48679) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Zo7TG-0001In-8A for 21699@debbugs.gnu.org; Mon, 19 Oct 2015 06:15:15 -0400 Received: from conversion-daemon.mtaout27.012.net.il by mtaout27.012.net.il (HyperSendmail v2007.08) id <0NWG00300PJ3FK00@mtaout27.012.net.il> for 21699@debbugs.gnu.org; Mon, 19 Oct 2015 13:10:23 +0300 (IDT) Received: from HOME-C4E4A596F7 ([84.94.185.246]) by mtaout27.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NWG00IQCPLBMV90@mtaout27.012.net.il>; Mon, 19 Oct 2015 13:10:23 +0300 (IDT) Date: Mon, 19 Oct 2015 13:14:35 +0300 From: Eli Zaretskii Subject: Re: bug#21699: 24.5; Bug in backup-buffer-copy and/or set-file-extended-attributes etc [set-file-extended-attributes] In-reply-to: X-012-Sender: halo1@inter.net.il To: Eli Barzilay Message-id: <83fv17go6s.fsf@gnu.org> References: <831tcricrz.fsf@gnu.org> <83zizfgxnl.fsf@gnu.org> <83wpujgwr3.fsf@gnu.org> <83si57gu7s.fsf@gnu.org> <83k2qjgqm5.fsf@gnu.org> X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 21699 Cc: 21699@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) > Date: Mon, 19 Oct 2015 05:47:36 -0400 > From: Eli Barzilay > Cc: 21699@debbugs.gnu.org > > > I don't know if this is important, but it does change the semantics of > > an interface that was already released. So I preferred a fix that > > didn't involve such changes. > > OK, here's a version that does the decision in > `set-file-extended-attributes', making it succeed if all of the given > attributes were set but ignoring the "null" values. (Again, I verified > that it works in my case.) > > ------------------------------------------------------------------------------- > (defun set-file-extended-attributes (filename attributes) > "Set extended attributes of file FILENAME to ATTRIBUTES. > > ATTRIBUTES must be an alist of file attributes as returned by > `file-extended-attributes'. Value is t if the function succeeds > in setting all of the given attributes excluding ones that > indicate \"no information\"." > (let ((result t)) > (dolist (elt attributes) > (let ((attr (car elt)) > (val (cdr elt))) > (unless (cond ((eq attr 'acl) > (or (equal val nil) > (set-file-acl filename val))) > ((eq attr 'selinux-context) > (or (equal val '(nil nil nil nil)) > (set-file-selinux-context filename val)))) > (setq result nil)))) > result)) > ------------------------------------------------------------------------------- Thanks. I'll let others to express opinions on this alternative vs the one I committed. The difference is what happens when all the attribute values are "null" values: your version returns t in that case, and I'm not sure that's correct, see below. > >> With my fix, `file-extended-attributes' would just return nil in > >> that case, and `set-file-extended-attributes' will succeed > >> trivially. > > > > Why should set-file-extended-attributes succeed in this case? It > > didn't set any extended attributes, right? > > Well, it did set all of the specified attributes, since there were none > of them. My new fix above will succeed in this case because it will > ignore all of them. > > > > And if neither ACLs nor SELinux is supported, we should definitely > > fall back on chmod for the backup files, shouldn't we? > > But chmod is not done on backup files other than copy the original bits > to the backup. Yes, I'm talking specifically about that scenario. We should fall back on chmod in that scenario, shouldn't we? And if chmod fails, as it did for you, shouldn't we tell the user about that? From debbugs-submit-bounces@debbugs.gnu.org Thu Oct 22 01:43:38 2015 Received: (at 21699) by debbugs.gnu.org; 22 Oct 2015 05:43:38 +0000 Received: from localhost ([127.0.0.1]:60134 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Zp8f4-0001Bv-50 for submit@debbugs.gnu.org; Thu, 22 Oct 2015 01:43:38 -0400 Received: from mail-ig0-f178.google.com ([209.85.213.178]:35279) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Zp8f2-0001Bn-4j for 21699@debbugs.gnu.org; Thu, 22 Oct 2015 01:43:36 -0400 Received: by igbkq10 with SMTP id kq10so114186060igb.0 for <21699@debbugs.gnu.org>; Wed, 21 Oct 2015 22:43:35 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=p2u/ZRI70CcKf9y9kwJWYhml5q1C2DygRbCrjCDlDSI=; b=GnDYZs3WXBtZSGyzzDHobA+FnW2kSzUskPNIgevGMrEXoz3FwJI6qGuseZ5QtxVPpQ fhKrZIoRwKaNB3jBwoXrgweBZilQHLlQGP9aBDWpmkAHKXo7SrTG0VIXxf+K1/GoNM/5 Qiyng5ttduOoa8gV3t1WRIQ8kwN2Hlzt5JwGw9RTUWxnNAukRWJItW/psfjHBfiuAxIP rPwu4vGT6PhnWDpSlMd1kUuFe7AX5JgUDgzDaVzF5KBhme+owvf/3zcrsCLSxFXiFbYW DmwnrrfNwNhTHPnQ44EKlOWd4ZqdjdRMf1LLFAfNaJZNAxWn+QkexSRe/+CiSytgNNgx VG4Q== X-Gm-Message-State: ALoCoQmCHhCk8FCgyxQTswVW5q0LauV+5IKVNcDXCqNzi7/87ffpTVJ15nERe4nZCuG05hwwYtSw MIME-Version: 1.0 X-Received: by 10.50.137.97 with SMTP id qh1mr15217691igb.60.1445492615524; Wed, 21 Oct 2015 22:43:35 -0700 (PDT) Received: by 10.79.28.211 with HTTP; Wed, 21 Oct 2015 22:43:35 -0700 (PDT) In-Reply-To: <83fv17go6s.fsf@gnu.org> References: <831tcricrz.fsf@gnu.org> <83zizfgxnl.fsf@gnu.org> <83wpujgwr3.fsf@gnu.org> <83si57gu7s.fsf@gnu.org> <83k2qjgqm5.fsf@gnu.org> <83fv17go6s.fsf@gnu.org> Date: Thu, 22 Oct 2015 01:43:35 -0400 Message-ID: Subject: Re: bug#21699: 24.5; Bug in backup-buffer-copy and/or set-file-extended-attributes etc [set-file-extended-attributes] From: Eli Barzilay To: Eli Zaretskii Content-Type: text/plain; charset=UTF-8 X-Spam-Score: 0.3 (/) X-Debbugs-Envelope-To: 21699 Cc: 21699@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.3 (/) On Mon, Oct 19, 2015 at 6:14 AM, Eli Zaretskii wrote: > > Thanks. I'll let others to express opinions on this alternative vs > the one I committed. The difference is what happens when all the > attribute values are "null" values: your version returns t in that > case, and I'm not sure that's correct, see below. Ah, you're talking about this code from `backup-buffer-copy': (unless (and extended-attributes (with-demoted-errors (set-file-extended-attributes to-name extended-attributes))) ...) In that case, I think that my slightly earlier fix which made `file-extended-attributes' drop "null" values is actually fine: it means that in the above snipped `extended-attributes' will be nil, and the chmod code will run. There is another use of a similar pattern (look for an "If set-file-extended-attributes fails" comment which appears in both places) where this second one should also have the same `and'. (The current state is messy anyway, since with your current fix, the `and' in the above is not needed, and anyway, `extended-attributes' is never nil.) FWIW, there is no real loss of information for doing that: `extended-attributes' currently adds acl and selinux entries always, with my fix (of dropping the no-info values) you can tell when there was no information for acl/selinux just by the fact that there is no such element in the `extended-attributes' result. -- ((x=>x(x))(x=>x(x))) Eli Barzilay: http://barzilay.org/ Maze is Life! From debbugs-submit-bounces@debbugs.gnu.org Fri Oct 23 04:26:33 2015 Received: (at 21699) by debbugs.gnu.org; 23 Oct 2015 08:26:33 +0000 Received: from localhost ([127.0.0.1]:33745 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZpXgG-0000yB-DU for submit@debbugs.gnu.org; Fri, 23 Oct 2015 04:26:32 -0400 Received: from mtaout29.012.net.il ([80.179.55.185]:49855) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZpXfv-0000xY-GO for 21699@debbugs.gnu.org; Fri, 23 Oct 2015 04:26:30 -0400 Received: from conversion-daemon.mtaout29.012.net.il by mtaout29.012.net.il (HyperSendmail v2007.08) id <0NWN00100Z65HQ00@mtaout29.012.net.il> for 21699@debbugs.gnu.org; Fri, 23 Oct 2015 11:25:04 +0300 (IDT) Received: from HOME-C4E4A596F7 ([84.94.185.246]) by mtaout29.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NWN00NX0ZDSXX30@mtaout29.012.net.il>; Fri, 23 Oct 2015 11:25:04 +0300 (IDT) Date: Fri, 23 Oct 2015 11:25:45 +0300 From: Eli Zaretskii Subject: Re: bug#21699: 24.5; Bug in backup-buffer-copy and/or set-file-extended-attributes etc [set-file-extended-attributes] In-reply-to: X-012-Sender: halo1@inter.net.il To: Eli Barzilay , Paul Eggert Message-id: <83bnbqrnxy.fsf@gnu.org> References: <831tcricrz.fsf@gnu.org> <83zizfgxnl.fsf@gnu.org> <83wpujgwr3.fsf@gnu.org> <83si57gu7s.fsf@gnu.org> <83k2qjgqm5.fsf@gnu.org> <83fv17go6s.fsf@gnu.org> X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 21699 Cc: 21699@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) > Date: Thu, 22 Oct 2015 01:43:35 -0400 > From: Eli Barzilay > Cc: 21699@debbugs.gnu.org > > On Mon, Oct 19, 2015 at 6:14 AM, Eli Zaretskii wrote: > > > > Thanks. I'll let others to express opinions on this alternative vs > > the one I committed. The difference is what happens when all the > > attribute values are "null" values: your version returns t in that > > case, and I'm not sure that's correct, see below. > > Ah, you're talking about this code from `backup-buffer-copy': > > (unless (and extended-attributes > (with-demoted-errors > (set-file-extended-attributes to-name extended-attributes))) > ...) > > In that case, I think that my slightly earlier fix which made > `file-extended-attributes' drop "null" values is actually fine: it means > that in the above snipped `extended-attributes' will be nil, and the > chmod code will run. There is another use of a similar pattern (look > for an "If set-file-extended-attributes fails" comment which appears in > both places) where this second one should also have the same `and'. > > (The current state is messy anyway, since with your current fix, the > `and' in the above is not needed, and anyway, `extended-attributes' is > never nil.) > > FWIW, there is no real loss of information for doing that: > `extended-attributes' currently adds acl and selinux entries always, > with my fix (of dropping the no-info values) you can tell when there was > no information for acl/selinux just by the fact that there is no such > element in the `extended-attributes' result. Paul (or anyone else), any second opinions about this? Thanks. From debbugs-submit-bounces@debbugs.gnu.org Fri Apr 22 09:27:33 2022 Received: (at 21699) by debbugs.gnu.org; 22 Apr 2022 13:27:33 +0000 Received: from localhost ([127.0.0.1]:52019 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nhtJs-0002C1-UP for submit@debbugs.gnu.org; Fri, 22 Apr 2022 09:27:33 -0400 Received: from quimby.gnus.org ([95.216.78.240]:38724) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nhtJr-0002Bh-2M for 21699@debbugs.gnu.org; Fri, 22 Apr 2022 09:27:31 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnus.org; s=20200322; h=Content-Type:MIME-Version:Message-ID:In-Reply-To:Date: References:Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=+v2e4yqXKAXrbJJ9aTDLDxiJQdyS/QDj9kQC4Goay2o=; b=OhgStUSIK50IkFKMOQAX24mTVT ZnvvZJ05frCqYZgDcKR9z89dH6+XaVsJps7plPYN/3g8hQVv25cu3ymUzC5HeBz5zY28Gde43iGum 4GEFMMROw0b4zSjX+hj/SoyAt5E3Sknh5Bw8R6vpvhMzDa9X8szYHvHFaxEbdps/zVnE=; Received: from [84.212.220.105] (helo=xo) by quimby.gnus.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1nhtJh-0006sj-Al; Fri, 22 Apr 2022 15:27:23 +0200 From: Lars Ingebrigtsen To: Eli Zaretskii Subject: Re: bug#21699: 24.5; Bug in backup-buffer-copy and/or set-file-extended-attributes etc References: <831tcricrz.fsf@gnu.org> <83zizfgxnl.fsf@gnu.org> <83wpujgwr3.fsf@gnu.org> <83si57gu7s.fsf@gnu.org> <83k2qjgqm5.fsf@gnu.org> <83fv17go6s.fsf@gnu.org> <83bnbqrnxy.fsf@gnu.org> X-Now-Playing: ELpH's _Protection_: "Untitled" Date: Fri, 22 Apr 2022 15:27:20 +0200 In-Reply-To: <83bnbqrnxy.fsf@gnu.org> (Eli Zaretskii's message of "Fri, 23 Oct 2015 11:25:45 +0300") Message-ID: <87h76lxn7r.fsf_-_@gnus.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Report: Spam detection software, running on the system "quimby.gnus.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see @@CONTACT_ADDRESS@@ for details. Content preview: Eli Zaretskii writes: >> FWIW, there is no real loss of information for doing that: >> `extended-attributes' currently adds acl and selinux entries always, >> with my fix (of dropping the no-info values) you can tell when [...] Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 21699 Cc: Eli Barzilay , Paul Eggert , 21699@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) Eli Zaretskii writes: >> FWIW, there is no real loss of information for doing that: >> `extended-attributes' currently adds acl and selinux entries always, >> with my fix (of dropping the no-info values) you can tell when there was >> no information for acl/selinux just by the fact that there is no such >> element in the `extended-attributes' result. > > Paul (or anyone else), any second opinions about this? (I'm going through old bug reports that unfortunately weren't resolved at the time.) This was six years ago, and it doesn't seem like anybody had an opinion. Skimming this bug report, it seems like the fix in f1575763c0d fixed the reported problem, so I'm closing this bug report. If I misunderstood, please respond to the debbugs address and we'll reopen. -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no From debbugs-submit-bounces@debbugs.gnu.org Fri Apr 22 09:27:37 2022 Received: (at control) by debbugs.gnu.org; 22 Apr 2022 13:27:38 +0000 Received: from localhost ([127.0.0.1]:52022 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nhtJx-0002CH-FH for submit@debbugs.gnu.org; Fri, 22 Apr 2022 09:27:37 -0400 Received: from quimby.gnus.org ([95.216.78.240]:38742) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nhtJv-0002Bp-P2 for control@debbugs.gnu.org; Fri, 22 Apr 2022 09:27:36 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnus.org; s=20200322; h=Subject:From:To:Message-Id:Date:Sender:Reply-To:Cc: MIME-Version:Content-Type:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:In-Reply-To:References:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=PxJdocYArP8732NUOK782YbCOJvxAI9aizjfX2/T8jw=; b=TmOA2Vcy6UvOFD0DrB4HiBt8vr oy9HaoD+vd71imtI84P+LQTQqCOV+jx97GQTGI4x3kf57cQMgr+IB89a8u5JjEUd7v1sTmjwdMUre DbUVVy8HuC1jSu/fvSCeXlU4WpPKFAgSSYroTV20ikW166GbkGJsSkc7E5pkb+MG7JmE=; Received: from [84.212.220.105] (helo=xo) by quimby.gnus.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1nhtJo-0006su-A2 for control@debbugs.gnu.org; Fri, 22 Apr 2022 15:27:30 +0200 Date: Fri, 22 Apr 2022 15:27:27 +0200 Message-Id: <87fsm5xn7k.fsf@gnus.org> To: control@debbugs.gnu.org From: Lars Ingebrigtsen Subject: control message for bug #21699 X-Spam-Report: Spam detection software, running on the system "quimby.gnus.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see @@CONTACT_ADDRESS@@ for details. Content preview: close 21699 quit Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: control X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) close 21699 quit From unknown Fri Jun 20 18:09:44 2025 Received: (at fakecontrol) by fakecontrolmessage; To: internal_control@debbugs.gnu.org From: Debbugs Internal Request Subject: Internal Control Message-Id: bug archived. Date: Sat, 21 May 2022 11:24:08 +0000 User-Agent: Fakemail v42.6.9 # This is a fake control message. # # The action: # bug archived. thanks # This fakemail brought to you by your local debbugs # administrator