Package: emacs;
Reported by: Eli Barzilay <eli <at> barzilay.org>
Date: Sun, 18 Oct 2015 04:36:02 UTC
Severity: normal
Found in version 24.5
Done: Lars Ingebrigtsen <larsi <at> gnus.org>
Bug is archived. No further changes may be made.
Message #32 received at 21699 <at> debbugs.gnu.org (full text, mbox):
From: Eli Barzilay <eli <at> barzilay.org> To: Eli Zaretskii <eliz <at> gnu.org> Cc: 21699 <at> debbugs.gnu.org Subject: Re: bug#21699: 24.5; Bug in backup-buffer-copy and/or set-file-extended-attributes etc Date: Mon, 19 Oct 2015 03:57:13 -0400
[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 <eliz <at> gnu.org> wrote:
>> Date: Sun, 18 Oct 2015 17:05:43 -0400
>> From: Eli Barzilay <eli <at> barzilay.org>
>> Cc: 21699 <at> debbugs.gnu.org
>>
>> On Sun, Oct 18, 2015 at 12:01 PM, Eli Zaretskii <eliz <at> gnu.org> 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-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)"
>> 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.
--
((x=>x(x))(x=>x(x))) Eli Barzilay:
http://barzilay.org/ Maze is Life!
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.