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

[Eli Zaretskii]

> 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.

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.