Mapping inode numbers to file names

[jc-8FIgwK2HfyJMuWfdjsoA/w at public.gmane.org (John Chambers)]

[Mimicking the top-posting here ;-]

In Edward's scenario, you actually know something more that could be used  to
radically trim the search.  You know the path to the file.  Even if these are
different "in real life", you can still use them.  What you do is trace  back
up  the  path,  using stat() to get the inode number of each directory in the
path.  Then, starting at the root, you search for the  inode  number  of  the
first  directory, and get its name.  You then abandon the root directory, and
search the first-level directory for the second inode number  in  your  list.
And  so on.  This way, you trim away most of the directory tree at each pass,
and only go down into the directories whose inode numbers match those in  the
path to the file you're looking for.

I haven't actually tried this, but it seems that if the inode numbers are all
preserved (which they'd have to be if the directory tree is to work), then it
should work.  The number of comparisons would then be roughly half the  total
number  of  entries  in all the directories in the pathname, rather than half
the number of files in the entire filesystem.

The find command can't do this, of course, because it generally doesn't  have
the  path  for  anything.   It's  trying  to find the path from relative to a
directory, with no path-related clues.

#To: <discuss-bounces-mNDKBlG2WHs at public.gmane.org> (Jerry Feldman)
| Essentially this is inherent in the design of the Unix/Linux file
| systems. Possibly some indexing utility, like beagle, or possibly by
| writing a specialized version of find. The 'find' command is a brute
| force utility that recursively searches through a directory tree. The
| inode contains a count, so you know the maximum number of links, so when
| you have found all those links you can stop. You can also multi-task the
| search.  I do seem to remember that there was another utility to do
| inode searches more quickly than 'find', but that might have been on
| Tru64 Unix.
|
| On 04/27/2010 09:22 AM, Edward Ned Harvey wrote:
| > Let's suppose you rename a file or directory.
| >
| > /tank/widgets/a/rel2049_773.13-4/somefile.txt
| >
| > Becomes
| >
| > /tank/widgets/b/foogoo_release_1.9/README
| >
| > =20
| >
| > Let's suppose you are now working on widget B, and you want to look at =
| the
| > past zfs snapshot of README, but you don't remember where it came from.=
|
| > That is, you don't know the previous name or location where that file u=
| sed
| > to be.  One way you could do it would be:
| >
| > =20
| >
| > Look up the inode number of README.  (for example, ls -i README)
| >
| >                 (suppose it's inode 12345)
| >
| > find /tank/.zfs/snapshot -inum 12345
| >
| > =20
| >
| > Problem is, the find command will run for a long time.
| >
| > =20
| >
| > Is there any faster way to find the file name(s) when all you know is t=
| he
| > inode number?  (Actually, all you know is all the info that's in the pr=
| esent
| > directory, which is not limited to inode number; but, inode number is t=
| he
| > only information that I personally know could be useful.)

--
   _'
   O
 <:#/>  John Chambers
   +   <jc-8FIgwK2HfyJMuWfdjsoA/w at public.gmane.org>
  /#\  <jc1742-Re5JQEeQqe8AvxtiuMwx3w at public.gmane.org>
  | |