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 4:04 AM, Eli Zaretskii <eliz@gnu.org> wrote:
>> Date: Mon, 19 Oct 2015 03:50:04 -0400
>> From: Eli Barzilay <eli@barzilay.org>
>> Cc: 21699@debbugs.gnu.org
>>
>> *BUT* I doubt that this is a good idea, since on a system that
>> supports both acl and selinux-context you probably want a t result to
>> indicate that all of the extended settings worked.
>
> I don't think this is true.  Many (maybe most) systems support either
> ACLs or SELinux, and for them the function will incorrectly return
> nil.
>
> A better way might be to have a test of "null" attributes, and avoid
> calling the low-level APIs when the attributes are "null".  A separate
> issue, I think.

Did you have a look at my `file-extended-attributes' fix?  It does just
that: when the low-level functions return "null" (four nils in the
selinux case), then they won't get included in the result.  This frees
`set-file-extended-attributes' to require that all settings succeed.


And I think that there's one case where things would fail with your fix:
a linux machine that has selinux disabled will have this as the extended
attributes:

    ((acl . nil) (selinux-context . (nil nil nil nil)))

and your version of `set-file-extended-attributes' would fail when both
of these fail.  With my fix, `file-extended-attributes' would just
return nil in that case, and `set-file-extended-attributes' will succeed
trivially.

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