Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.2 9/18/84 SMI; site sun.uucp Path: utzoo!watmath!clyde!burl!ulysses!allegra!mit-eddie!genrad!decvax!decwrl!sun!guy From: guy@sun.uucp (Guy Harris) Newsgroups: net.unix-wizards Subject: Re: inode number -> pathname? (4.2BSD) Message-ID: <2420@sun.uucp> Date: Tue, 16-Jul-85 04:27:31 EDT Article-I.D.: sun.2420 Posted: Tue Jul 16 04:27:31 1985 Date-Received: Thu, 18-Jul-85 05:57:17 EDT References: <6727@Shasta.ARPA> <2071@ucf-cs.UUCP> <2414@sun.uucp> <274@ttrdc.UUCP> Organization: Sun Microsystems, Inc. Lines: 27 > ...why not > > find /file_system -inum inode_# -print [maybe -exec ls -l {} \;] > > which would restrict the search for the inum to the file system on the > device in question? Unfortunately, if something is mounted on a directory on /file_system, it will also search that file system. The 4.3BSD "find" may have a file to keep it from wandering across file systems. > Maybe it's still slower than ncheck (I haven't timed it yet). On my machine - Sun-2/120, SCSI disk, running Sun UNIX 2.0 (4.2BSD based) - I tried doing a "find /usr/src -inum..." ("/usr" is the file system, but I wanted to keep it from wandering onto other file systems) and an "ncheck". In this case, the "find" was faster. I don't know whether a find starting at /usr would have been slower than "ncheck" (I doubt it, since most things on /usr on my machine other than /usr/src are only a couple of levels deep). On the other hand, my /usr/src is not a complete UNIX source tree; trying it on a big Eagle-based file system might give different results. However, neither one is fast; the "find" took about 50 seconds from the time "time" fired it off to the time I hit my interrupt key after it printed the path name I was looking for. Guy Harris