From owner-freebsd-hackers  Mon Jan 22 00:49:13 1996
Return-Path: owner-hackers
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.3/8.7.3) id AAA20176
          for hackers-outgoing; Mon, 22 Jan 1996 00:49:13 -0800 (PST)
Received: from rover.village.org (rover.village.org [198.137.146.49])
          by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id AAA20162
          for <hackers@freebsd.org>; Mon, 22 Jan 1996 00:48:52 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by rover.village.org (8.6.11/8.6.6) with SMTP id BAA28985; Mon, 22 Jan 1996 01:48:27 -0700
Message-Id: <199601220848.BAA28985@rover.village.org>
To: hackers@freebsd.org
Cc: dworkin@rover.village.org
Subject: Two commands: icat and ils
Date: Mon, 22 Jan 1996 01:48:27 -0700
From: Warner Losh <imp@village.org>
Sender: owner-hackers@freebsd.org
Precedence: bulk

I have two commands that I've hacked together:
	icat:	Will list a file given its inode
	ils:	Will try all the inodes it can find and list all the
		files that seem sane in all the directories that are
		on a disk.  Or, alternatively, it can list just one
		inode as a directory.

Would there be any interest at all for me to clean up these tools
modestly and send them in?  They are, of course, the worlds largest
assault tanks in the battle of security, but they have come in *DAMN*
useful in recovering the disk that I was talking about earlier in my
"I have a disk that fsck dumps core on..."

And they should work on an "ordinary" file just as well as a raw
disk...

fsdb will run under 2.0R, btw, but it isn't useful when you have a
disk that is really really really trashed badly (since I can't keep
enough info in my head to repair it, and I'm scared to death to write
to it at all).  Oh, fsdb needs a -n option to preclude writing to the
disk...  Not a big deal, but certainly good for the paranoid amoung
us.

icat is due, in part, to an icat that Tom Christiansen posted a long
time ago.  Ils is a horrible hack on it, based a little on my peeks
into fsdb.

an idump that just went out and grabbed all the inodes that it could
find in directory entries would not be a totally bad thing to write as
well.  Maybe I'll do that to get this disk back.  Normal dump core
dumps after telling me that it will take -385692343 tapes to do the
dump of -148137595976235 blocks :-(.

The disk, btw, accepted commands for sd0 for a while (it was sd1) and
the ones that really hozed it good were the ones for swap and /tmp
:-(.  That's why fsck and dump both have difficulties with it.  This
was due, I theorize, to either power fluxations the disk had been
exposed to so it accepted sd0 commands, or a bad cabling job (I had
messed with the cables just before the disk went out to lunch).

Thanks to everyone that mailed me suggestions.  I now have a "mere"
33,868 diretory entries with inode != 0 to sift through and see what
is useful.  I did get back one set of books that I had online, and I
think I got back a set of records I was keeping for the IRS to show
business use of the computer[*]...  Time will tell how much else I got
back...

Warner

P.S. [*] Those among you that have been exposed to the IRS will
understand this is the PRIMARY motivator to getting these files
back...