Subject: Significant divergence in UFS?
To: None <current-users@netbsd.org>
From: Scott Ellis <scotte@warped.com>
List: current-users
Date: 06/08/2004 17:42:07
In an attempt to recover some data accidentally deleted by one of my users,
I've been trying to get either Sleuthkit or TCT working on a UFS1
filesystem, to no avail.
Using a relatively current machine (2.0F) I created a small directory tree
for testing:
intrepid: {222} ls -lR SEDir.source
total 16
drwxr-xr-x 2 scotte wheel 512 Jun 8 17:20 DelDir
-rw-r--r-- 1 scotte wheel 29 Jun 8 17:19 DelFile
drwxr-xr-x 2 scotte wheel 512 Jun 8 17:19 KeepDir
-rw-r--r-- 1 scotte wheel 33 Jun 8 17:19 KeepFile
SEDir.source/DelDir:
total 4
-rw-r--r-- 1 scotte wheel 71 Jun 8 17:20 KeepFile
SEDir.source/KeepDir:
total 4
-rw-r--r-- 1 scotte wheel 50 Jun 8 17:19 KeepFile2
...and then proceeded to make an image of it using makefs, mount it to a
vnd, delete the "DelDir" and "DelFile" parts, then unmount/unvnconfig the
file so I could practice file recovery.
Unfortunately, the tools from SleuthKit and TCT don't seem to operate as
expected, and my gut tells me it's due to a divergence of NetBSD's on-disk
format from that of the other BSD's.
The "fls" command starts at the root inode (2), and looks at the dinode:
intrepid: {212} /misc/sleuthkit-1.70/bin/fls sedir.img
r/r 3: KeepFile
r/- * 4: DelFile
d/d 5: KeepDir
d/- * 6: DelDir
So far, so good. We can see that inode 4 is where the deleted "DelFile"
should live. So, we use the "ils" command to look at properties of that
inode:
intrepid: {213} /misc/sleuthkit-1.70/bin/ils sedir.img 4
class|host|device|start_time
ils|intrepid|sedir.img|1086740772
st_ino|st_alloc|st_uid|st_gid|st_mtime|st_atime|st_ctime|st_mode|st_nlink|st
_size|st_block0|st_block1
4|f|100|0|1086740653|1086740502|1086740653|0|0|0|0|0
Note that st_block is zero, when it should contain the disk block that is
referenced by that inode. Indeed, trying to just cat the contents of that
inode returns nothing as well:
intrepid: {214} /misc/sleuthkit-1.70/bin/icat sedir.img 4
intrepid: {215}
Am I missing something fundamental here, or is NetBSD significantly
different enough from the other BSD's that these tools just aren't working?
I tried examining the dirent and inode structs that SleuthKit thought it
should use, and comparing those to what NetBSD has in dirent.h and fs.h, but
nothing jumped out at me.
Clues?
ScottE