Chris Gehlker wrote:
Awhile back I was asking for help with a unixy way to search the mounted
volumes on my OSX machine for executable files. With help from you all, I
came up with a system call that worked but it was taking over two minutes.
To find all the files on the system means to walk the entire directory
tree, starting at ‘root’. There’s a lot going on behind the scene.
how UNIX has always been. It’s not DOS, CPM, AmigaDOS, Atari DOS, OS/2,
VMS, RT-11, RSTS, …
Note that there’s no user access to the raw file-system information.
If a normal user can read the hard-drive, then they can bypass
all file permissions. Can’t have that, now can we?
(Of course, we can all think up twenty ways to fix it!
My first working version, debug code and all, runs in about 0.2 seconds.
Was that on a freshly booted system?
If you tried it after running a regular ‘find’,
all the information might have been in the buffer cache.
The first time I do a “find /”, it does take a little while.
When I repeat it, it takes about one second
to generate about 110K lines, about 5 MB.
It did the same amount of work walking the directory tree,
but all the directories and disk blocks were in the buffer cache.
Are the unix file inquiry tools just really
slow on Mac OSX or are they slow everywhere?
Specifically, you mean the time to search the entire file-system
structure, enumerating all path names?
Did Unix sacrifice efficiency for portability?
Well, there’s always that trade off, isn’t there?
How often does the typical administrator need a complete
list of files on the system? Both official and user-made?
“find /” isn’t a high-priority event in the life of a system.
My answer to your question: No, I don’t think so.
Even more off thread: old V7 UNIX had some commands called
’icheck’ and ‘ncheck’. They could do cool things like convert
a inode-number to a path name, and generate a list of file-names
and inum’s directly from the file-system image on the disk.
Needed to be root, since it read the disk directly.
Nowadays, with ext2, ufs, fat, Reiser, and other file-systems,
you’d need lots of different versions of those commands.