bug#21699: 24.5; Bug in backup-buffer-copy and/or set-file-extended-attributes etc

[Eli Barzilay <eli@barzilay.org>]

[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@gnu.org> wrote:
>> Date: Sun, 18 Oct 2015 17:05:43 -0400
>> From: Eli Barzilay <eli@barzilay.org>
>> Cc: 21699@debbugs.gnu.org
>>
>> On Sun, Oct 18, 2015 at 12:01 PM, Eli Zaretskii <eliz@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!