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

[Eli Zaretskii <eliz@gnu.org>]

> Date: Mon, 19 Oct 2015 02:14:40 -0400
> From: Eli Barzilay <eli@barzilay.org>
> Cc: 21699@debbugs.gnu.org
> 
> > 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.
> 
> Getting from -Q to a point where the bug(s) are visible means recreating
> the same backup configuration which will take a while.  I'll try to get
> that kater, though I don't know how effective that will be.

Please do, I think it's important to start from a known behavior that
we understand.

> >> 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.
> 
> Yes, I'm saying that it *does* AFAICT always return nil, hence the bug.
> 
> 
> > When it succeeds, it returns t.  It returns nil in your case because
> > it fails; the question is why.
> 
> Its body is a single `dotimes' expression, and that always returns nil
> -- do you see any way in which it will return anything else?

Ah, yes, you are right.  I was instead looking at what set-file-acl
returns.

So after fixing set-file-extended-attributes as you suggest, does the
problem still happen for you?