From: Mike Hall Date: 2002-06-15T09:33:56+09:00 Subject: Re: OT!!! Are Unix tools just slow? 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. It's just 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. -- Mike Hall http://www.enteract.com/~mghall