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