Extended attributes with find

Bookmark and Share

Extended attributes are a fun feature of the Linux filesystem (or rather, all the major Linux filesystems — ext2, ext3, reiser, xfs, etc.) that lets you associate arbitrary metadata with a file. find is, of course, a program that lets you find stuff. Files, specifically; you give it a bunch of criteria and it finds everything in a given directory that meets those criteria, and then does whatever you want with them. But oddly enough, find can’t find files based on their extended attributes. Why? I suspect a couple of reasons: (1) the behavior of find is specified by the POSIX standard, so the priority of the developers is to make sure they implement the features prescribed by POSIX correctly, and (2) extended attributes are an optional feature on filesystems; they have to be explicitly enabled when you’re compiling your kernel and again when you mount your filesystem if you want them to exist at all. A core utility like find can’t afford to include code for an optional feature that might b0rk things when the feature is not enabled.

Thankfully, I don’t care about any of that. So I took a day off website design (that was the real point, I was getting sick of Python) to patch an -xattr attribute into find. This lets you do things like

find /home/user -xattr user.rofl

to pick out all the files in /home/user which have the extended attribute user.rofl set. Right now it can only test for the presence of extended attributes, not their values, but that’ll probably be the next thing I’ll add if/when I need it (or if people start asking for it).

Here’s the patch and, for users of the One True Distribution (lol kidding), an ebuild which enables extended attribute support if the xattr USE flag is set. If you’re compiling manually, pass the –enable-xattr-predicate option to configure.

Please note that at the time of writing, this is largely ad-hoc, untested code, distributed AS-IS with NO WARRANTY etc. and no assurance whatsoever of performance, correctness, or not crashing your system. License is the usual GPLv2 for the ebuild and GPLv3+ for the patch, and I would appreciate notice of any necessary corrections you find.

EDIT: As I should have suspected, this has been done already, by Leslie Polzer as a Google Summer of Code project. Undoubtedly that project is much more robust than my simple 6-hour hack, but for the life of me I couldn’t find a patch for it, and I have a funny feeling that I could have spent more time looking than it took me to add the darn thing in the first place. But from what I can tell, the plan is to eventually merge that SoC project into the official find source tree, which would be great.