Re: Can GNU-find command search by xattrs?

On Wed, Dec 31, 2025 at 04:21:14PM +0100, Bernhard Voelker <[email protected]> wrote:

> On 12/30/25 17:45, Peter B. wrote:
> > I'll also checkout Morgan's find-patch:
> > I'd really love to see xattr-support in the basic "most likely to be
> > present-on-any-box" tools.
> 
> The technical coding under the hood for reading xattr from the file system
> is there in Morgan's patch for quite a while, indeed.
> 
> But before adding, I feel we need to discuss once again the interface
> to the find(1) user:
> 
> - Do we only want to provide an option to search for files having xattrs?
>     find -xattr
> 
> - Do we want a test option to search for a file having an xattr key matching
>   a certain string (or eventually pattern)?
>     find -xattr 'mykey'        # xattr key equals string
>     find -xattr '*mykey*'      # xattr key matches pattern
>   Or better explicitly mention in the option that we match for the xattr keys?
>     find -xattr-key 'mykey'
>     find -xattr-key '*mykey*'
> 
> - Do we want a test option to search for a file having an xattr value matching
>   a certain string (or eventually pattern)?
>     find -xattr-value 'myval'   # files with xattr value equals string
>     find -xattr-value '*myval*' # ... or pattern
> 
> - Or search for files with xattr having a certain mixture of 'key=val'?
>     find -xattr-match 'mykey=myval'      # search by key+val as strings
>     find -xattr-match 'mykey=*someval*'  # search for key matching a val pattern

There are versions of find that (I think) use -xattr to
just identify the existence of EAs. I don't think
that's enough, but it might make sense to have -xattr
do that (for compatibility with those other versions of
find), but to also have -xattr-key and -xattr-value (or
-xattr-match for both).

The thing to watch out for if both the key and value
are combined, is that if you format it like "key=value"
you need to consider the case where the key includes
"=". There might be malicious EAs trying to be tricky.

My rawhide program matches EAs formatted like "key:
value" but non-ascii bytes are encoded (like \x1b or \n
or \t etc.) and any ": " in the key itself is encoded
as "\x3a " to disappoint the creators of malicious EAs.
I've never seen an EA whose key contained ": " so I
don't think it'll bother anyone.

I don't think -xattr-key and -attr-value are any good
because the value might not match the key. I think the
key and the value need to be combined/encoded together
in some way so that they are matched together.

I'd vote for just -xattr and -regexxattr (and maybe
-ixattr and -iregexxattr) and have it match text that
looks like "key1=val1\nkey2=val2\nkey3=val3\n" or
"key1: val1\nkey2: val2\nkey3: val3\n".

> - Do we need support for -printf formats to print xattr keys and/or values?
>   How? The % 1-character directives are almost all used, maybe begin with
>   the reserved ones? (%{ %[ %(
>   How to output several xattr keys or values?
>   How to select which xattr value to print?
>     find -xattr -printf '%p %{xattr-keys=hello*} %{xattr-valuekey=hello}

There are plenty of conversion letters available!

See https://savannah.gnu.org/bugs/?64100

I submitted a wish to the issue tracker asking to
reserve certain -printf conversions so that, if they
are ever implemented, they'd be compatible with my
rawhide program (which of course tries to be compatible
with find). Its equivalent of -printf uses %x for
extended attributes as an encoded comma-separated list.
It shows pretty much what the user would need to match
for (except that the matched text contains a newline
between each EA rather than a comma). It's a bit
rubbish, because commas in the names or values aren't
encoded to avoid ambiguity. :-( But they are in the
next version. :-)

%x can't cope with selecting individual EAs to output,
but %j can (see below). I think they serve different purposes
in rawhide. %x shows the user what to match against, and
%j lets them do whatever they want with EAs.

> There's a lot of possibilities, and I don't want to introduce something
> which contradicts the typical use cases, or is not extensible or not
> maintainable.
> The complexity - especially when it comes to -printf - is that files can have
> several xattr while all other attributes (name, timestamps, permissions, size,
> etc.) only exists once.

My rawhide program also has %j for JSON output. The
current version outputs EAs like %x but the next
version outputs them as a JSON object with key/value
pairs matching the EA names and values. It's still
encoded because EA values can be text or binary and
JSON can't represent binary without the user choosing
some encoding. So that's something to think about.
 
> I think I asked this kind of questions already some years ago, but there was
> no input yet.
> I personally don't have a use case to search for xattrs, so the usual pattern
> with '-exec getfattr ...' works for me.
> Anyone?
> 
> P.S. Finally, I wouldn't want to introduce too much and complex code for
> 0.25% use cases.  Eventually, the simple test to search for files having
> xattrs is enough, and the application logic then extracts them with another
> tool.

I don't think it's necessarily too complex. The code in
rawhide to obtain EAs is 492 lines (335 excluding
blanks line, 278 excluding comment lines as well) for
Linux, macOS, Cygwin, Solaris, and FreeBSD (OpenBSD and
NetBSD don't have EAs). But of course, that's only the
start.

> Have a nice day,
> Berny

And Happy New Solar Orbit!
raf