Re: A proposal for Summer of Code.

[Debarshi 'Rishi' Ray]

> > However the current Findutils components do not look at the meta-data
> > of the files on the filesystems. They only look at file names.

> No, they (for example the "find" command) also look at things like
> size, permissions, accessibility, sparseness, ownership, filesystem
> name, and so forth.  Take a look at the manual page.

Sorry for the confusion. Surely 'find' does look at those things, but
by the term 'meta-data', I was referring to things like artist, title,
genre (for songs); author (for documents); description, photographer,
resolution (for pictures); to, from, subject (for emails); and so on.

> >  Moreover the presence of
> > packages like GNU Libextracter
> > (http://www.gnu.org/software/libextractor) make it really easy to
> > extract the meta-data from various kinds of files using on a X-less
> > installation. One can keep writing back-ends for handling more and
> > more file types to Libextractor to broaden its support base.

> I'm not familiar with that library, but the web page is not currently
> working either.

Oops! Maybe you can try this one: http://gnunet.org/libextractor/

> > We can either modify the existing updatedb and locate tools, or write
> > some separate meta-data capable components for Findutils.

> Are you perhaps suggesting that "locate" be enhanced to provide more
> of the tests offered by "find"?

Yes. I feel is no harm if 'find' can also be enhanced to look at
things like artist, title, genre (for songs); author (for documents);
description, photographer, resolution (for pictures); to, from,
subject (for emails); and so on. But looking at all these things
on-the-fly may make 'find' really slow. Therefore to obtain the
maximum benefit it may be preferable to have something which maintains
an index as 'locate/updatedb' already does.

Have I made things a bit clearer now?

Regards,
Debarshi
--
GPG key ID: 63D4A5A7
Key server: pgp.mit.edu