Re: Can GNU-find command search by xattrs?

Hi!

I'm super happy to see that I'm not the only one anymore interested in 
increased xattr, and  therefore possible key/value usage and query 
functionality!

😀️

**I'm writing this with personal interest**
Yes, we ALL have data to deal with, and I like to tag and find my kids' 
photos and files - regardless which "app" or system-

**as well as my professional interest**
Working with small-to-medium-to-very-very-large digital heritage 
collections.

(And therefore loads of meta+data wrangling clever-hacks-and-stunts for 
a living 😉️)


So, my hopefully useful "few-cents" to this thread are here:

On 1/2/26 13:11, raf wrote:
> 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

+1
absolutely agree.
To both: useful and not-enough.


> (for compatibility with those other versions of
> find), but to also have -xattr-key and -xattr-value (or
> -xattr-match for both).

+1 again.
It indeed makes perfect sense (and has use-cases!) where one wants to 
query (key OR value) AND (key AND value).

A lot useful if that provides some RegEx (for matching wildcards/patterns).


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

True.
There will always be potential for malicious attempts, yet I would 
suggest to apply basic "query-escaping", until more strict antitrust 
seems necessary?


> 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 think we're on the same page here :)
Yet, one may say "xattrs are not-yet-popular enough, but you'll see, 
once they do..." - like with all formats and data-exchange protocols, I 
guess?

I believe if good software make people happy = less people interested in 
breaking things ;)


> 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 disagree (If I understand you correctly). No hard feelings :D

What if:
- I search for "some term", but don't care if it's a key or value string?

I have that use-case a lot: plain fulltext search in collections.


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

I like args names that explain what they are, but just for "style" 
suggestion:

[quick bike-shedding]:
What if, you'd call it "--xattr" and "--xxattr" or "--xattRX/xattrx"? 
(like the "RX" at the end is "RegEx" :P)

Just an idea...

And I assume "ixattr" is "case Insensitive"?

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

Having quickly read over that thread, I totally agree "IF those features 
be added, IF possible, it'd be great if rawhide and find could stay 
syntax-compatible".

Also, I think (If I understood correctly) that some 
common-library-printf formatting syntax may save A LOT of re-occurring 
bash-or-python-style "formatting-caller-works-on-my-machine" scripts, I 
guess?
But I'm far out on a limb here; I've not really read the thread, and 
I've never used find-output formatting (as I didn't know it had any).


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

If any output data is available in a machine readable format (like 
JSON), it'd definitely make the re-usability and interoperability 
between tools (and scripts) written around find/rawhide, IMO (and 
experience).

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

ME! Meee! :)
As I said, I'm doing devops for digital-and-physical GLAM-collections - 
and a lot of metadata layout, storage and retrieval/usage.

For example:
After de-embedding (=copying as-is) all exiftool-readable metadata into 
xattrs, being able to do some queries on those key/value pairs is AMAZING!

Combining that with RDF URIs for keys, combined with 
Wikibase-and-Wikidata engine and data, I have many great use cases for 
xattrs (and find).


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

Is this about the code to handle xattrs (in `gnu-find`)?
There are libs for plain access to xattr key/value, but is there any 
xattr-libs for higher-level functions (like queries, regex, etc)?

Like what HaikuOS (probably?) does in their BeFS filesystem libraries?
A friend of mine (author of "https://sen-labs.org/": a semantic desktop 
engine for Haiku) told me that BeFS has some database-like query 
functions built-into their filesystem "xattrs".

I know any additional library-dependence is another "whole thing" to 
maintain.
However, IMO being able to query key/value data "on the spot" is 
something that will eventually replace the legacy "files-in-folders 
open/save dialogs - and wildcards" as-we-know-it...?

Might be an incentive to invest in a common, and commonly supported 
"attribute-handling" lib.
Just 2¢ of mine.

I just like interoperable and open tech-systems :)


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

Including so many OSs already in your consideration(s), wouldn't that 
already suffice for a common lib?
Ignore and correct me, if I'm totally on the wrong track here?
Thanks :)


> And Happy New Solar Orbit!

Does the sun actually do "new years eve"? O.O
I didn't know that.

Happy solar orbit bump #2026!

P.