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

[Eli Zaretskii <eliz@gnu.org>]

> From: Eli Barzilay <eli@barzilay.org>
> 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.