From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#21699: 24.5; Bug in backup-buffer-copy and/or set-file-extended-attributes etc Date: Mon, 19 Oct 2015 08:10:40 +0300 Message-ID: <838u6zigtr.fsf@gnu.org> References: <22051.8546.40000.221633@gargle.gargle.HOWL> <83wpuki2sf.fsf@gnu.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1445231485 30609 80.91.229.3 (19 Oct 2015 05:11:25 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 19 Oct 2015 05:11:25 +0000 (UTC) Cc: 21699@debbugs.gnu.org To: Eli Barzilay Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Mon Oct 19 07:11:14 2015 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Zo2j2-0006fH-RP for geb-bug-gnu-emacs@m.gmane.org; Mon, 19 Oct 2015 07:11:13 +0200 Original-Received: from localhost ([::1]:36500 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zo2j2-0003aW-0t for geb-bug-gnu-emacs@m.gmane.org; Mon, 19 Oct 2015 01:11:12 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:51270) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zo2ix-0003aL-1I for bug-gnu-emacs@gnu.org; Mon, 19 Oct 2015 01:11:08 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Zo2it-0001nc-Q2 for bug-gnu-emacs@gnu.org; Mon, 19 Oct 2015 01:11:06 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:36633) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zo2it-0001nW-Ma for bug-gnu-emacs@gnu.org; Mon, 19 Oct 2015 01:11:03 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1Zo2is-0002XI-R3 for bug-gnu-emacs@gnu.org; Mon, 19 Oct 2015 01:11:03 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 19 Oct 2015 05:11:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 21699 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 21699-submit@debbugs.gnu.org id=B21699.14452314459722 (code B ref 21699); Mon, 19 Oct 2015 05:11:01 +0000 Original-Received: (at 21699) by debbugs.gnu.org; 19 Oct 2015 05:10:45 +0000 Original-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 Original-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 Original-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) Original-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) In-reply-to: X-012-Sender: halo1@inter.net.il X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 208.118.235.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:107730 Archived-At: > 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.