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

From: Eli Zaretskii <[email-masked]>
Date: Mon, 19 Oct 2015 11:04:23 +0300

> Date: Mon, 19 Oct 2015 03:50:04 -0400
> From: Eli Barzilay <[email-masked]>
> Cc: [email-masked]
> 
> >> Actually, your suggested variant also returns nil for me.
> 
> Well, it would return nil since the result of `file-extended-attributes'
> would include (selinux-context nil nil nil nil)

It always does, AFAICT.

> > I installed a slightly different variant of this (which always invokes
> > the corresponding low-level primitive for each type of extended
> > attributes, instead of skipping all those after the first success), to
> > keep the original semantics.
> 
> Well, you added this in the docstring:
> 
>     Value is t if the function succeeds in setting the attributes.
> 
> which is a little vague -- I think that it would be better to say
> 
>     Value is t if the function succeeds in setting at least one of the
>     attributes.

We don't have enough information from the low-level APIs to tell
that.  So yes, it's slightly vague, but intentionally so.

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