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

[Eli Barzilay]

(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!