On 6/17/02 11:35 AM, "Josh Huber" <huber / alum.wpi.edu> wrote:

> Chris Gehlker <gehlker / fastq.com> writes:
> 
>> Guys, I *said* it was HFS+. The file system is a B*-tree in
>> memory. And the code doesn't just walk it, it searches it, recording
>> the path for files which match the search criteria. In this case the
>> search criterion is simply whether the user running the search has
>> execute permission for the file, either because she owns it and the
>> owner execute bit is set or because she is a member of the owner's
>> group and the group execute bit is set or because anyone can execute
>> the file.
> 
> Right, but find does not know/care what the filesystem type is --
> using the regular user-mode file i/o interface isn't going to give you
> access to the B-trees.  You could perhaps write an extention to find
> which uses this API, but it would be MacOS specific. (or rather,
> filesystem specific)
> 
> It's not that the tools are slow, it's that find does not use any sort
> of API which allows for direct access to the filesystem information.

We seem to have come full circle. I started these threads by asking whether
find and similar tools like stat sacrificed speed for portability across
file systems or whether they were sometimes optimized for particular file
systems. It seems that there my be optimized tools but they aren't called
'find', 'stat' or what have you.

So the question for Ruby is whether to live with what we have, add methods
to use the faster tools when they are available, or develop something fast
and portable using a database and FAM.
-- 
Laws are the spider's webs which, if anything small falls into them they
ensnare it, but large things break through and escape. -Solon, statesman
(c. 638-c558 BCE)