Re: [Findutils-patches] xattr and capability support

[Dale R. Worley]

> From: KillBoy PowerHed <address@hidden>
> 
> >If I understand you correctly, "-xattr regex" is true if the file has
> >an extended attribute whose name is matched by "regex".
> 
> >- Is the matching case sensitive?  (Is there any reason for it to be
> >  case-insensitive?)
> 
> I initially made it case-insensitive as capabilities are defined all
> uppercase in man pages (CAP_XXX) but the output from cap_to_text()
> is lower, it seemed reasonable that users may not know or care what
> case it was stored in, just whether or not it was present. What are
> your feelings on this?

Mostly I want to make sure that you have carefully thought through all
the issues.  But in this case, your response seems to be about
capability values, whereas I was asking about attribute names.

> >- Is the nature of the regex controlled by -regextype (as is -regex)?
> 
> It's currently hardcoded but I plan to support -regextype, maybe
> default to case-insensitive if -regextype is not defined.

My understanding is that all regexes in find are controlled by
-regextype, so the regex handling in any new predicates should work
the same way.  The particular syntax for the regex is set by
-regextype, but whether the regex is case-sensitive is determined by
whether the predicate starts with "i".  (E.g., -iname vs. -name,
-ilname vs. -lname)

The one exception I can see is if the datum you are testing is
inherently case-insensitive.  (E.g., if it is enforced that capability
bit names have only one case) In that case, there's no reason to
provide case-sensitive tests.

> >- If the current file name is a symbolic link, does -xattr test the
> >  symbolic link itself, or the file it points to?  (It's possible that
> >  symbolic links can never have extended attributes, in which case
> >  looking at the file that is pointed to would always make sense.)  Is
> >  this behavior affected by the -L option?  Or do we need a "-lxattr"
> >  test?
> 
> Extended attributes are supported on symlinks via a different
> call(llistxattr), I guess it should be supported even though there
> may not be much demand - is your preference to detect '-L' or offer
> '-lxattr' instead?

I would expect it to work like -name vs. -lname.  And the meaning of
both of these is modified by the -P, -L, -H, and deprecated --follow
options.

> >- Is there any way to test whether a particular attribute has a
> >  particular value, or matches a regex?  Is there any need for this?
> >  If there is:  It appears to me that the values can be binary
> >  strings; what do we have to do to allow comparison values to be
> >  specified (especially given that 0 bytes cannot appear in command
> >  arguments).  If the values can be binary strings, is there a need to
> >  provide a mask-and-test operation?
> 
> This is what '-cap' does, but in the case of capabilities the binary
> value needs to be interpreted correctly.  Tools that handle regular
> expressions as command line arguments will always support escaping
> of non-printing characters, so to match a binary '0' you would use
> '\0' in your regex.

That's true, but if it's common to have attributes whose octets are
interpreted as integers or bit-vectors, it is far easier on the user
to provide tests that treat them as such.  The important question is,
What will users want to do?

> Considering that a given extended attribute's value could contain
> any type of data that may or may not require interpretation I don't
> know that there's value in offering that functionality. Wouldn't
> this also require 2 arguments - <xattr_name> and <regex> ?

There are a number of ways that you could organize it.  For instance:

    -xattr name value-format test-value  -- -xattr foo.bigness i4 '>12'

But you could combine the format and test-value argument:

    -xattr name value-format:test-value  -- -xattr foo.bigness 'i4:>12'

At this point, it's more important to develop a complete list of what
users will want to do in practice than to worry about detailed syntax.

Dale