[ILUG] Command line args..

[kevin lyda]

"John P. Looney" burst across the net:
> What I'm actually doing is using find to gather info on the filesystem,
>and dumping it into a table regularly. Maybe later, I'll make a kernel
>thread that updates said databases, in realtime, but that can wait ;)

i think the bad times are due more to fs design and the layout of the
metadata then a lack of a db.  in fact the metadata is the db, and if
it were layed out in a smaller area of the disk (or on another disk)
it would be quicker.  the be fs is done like a db iirc.  but the way
unix accesses files, and authenticates access to files/dirs is probably
also an issue.  locate runs as nobody and therefore doesn't even
catalog all the files - what would your daemon do?

you might want to consider why this problem hasn't been solved.
i think a lot of people haven't found it necessary since it would slow
down operations done 99% of the time to speed up operations done 1%
of the time.

news servers actually try to *reduce* the amount of metadata written
(the noatime option) and that's an application that made the most use
of the fs as db concept.  i suspect the best answer would lie in writing
an fs that could quickly respond to find requests.

i'm not even 75% sure of some of these things, so it would be interesting
to know exactly what slows down find.

> Hmm. That's an idea. Just string a load of predicates together like find.
>How would you do an "or" ?
>
> (find / -user 288 -o -size +10k ; find / -user 20 -o -size +100k ) | uniq

-o

find / -user 288 -o -size +10k -o -user 20 -o -size +100k -print

if you wanted to look for files owned by 288 and > 10k or files
owned by 20 and > 100k you would do:

find / \( -user 288 -and -size +10k \) -o\( -user 20 -and -size +100k\) -print

the -and's are optional

kevin