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

[Eli Barzilay <eli@barzilay.org>]

On Mon, Oct 19, 2015 at 1:10 AM, Eli Zaretskii <eliz@gnu.org> wrote:
>>
>> 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.

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.  The main
bug is very visible though, but perhaps it got lost in details.  So I'll
talk about just that now.  (I'll update the subject accordingly.)

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

As a trivial test, I ran this:

    (set-file-extended-attributes ".emacs" nil)

and the result is the expected nil.

Fixing this bug, AFAICT, should look like

    (defun set-file-extended-attributes (filename attributes)
      "..."
      (let ((res t))
        (dolist (elt attributes)
          (let ((attr (car elt))
                (val (cdr elt)))
            (unless (cond ((eq attr 'acl)
                           (set-file-acl filename val))
                          ((eq attr 'selinux-context)
                           (set-file-selinux-context filename val)))
              (setq res nil))))
        res))

-- 
                    ((x=>x(x))(x=>x(x)))                   Eli Barzilay:
                    http://barzilay.org/                   Maze is Life!