RE: [sleuthkit-users] dls rawfs_block_walk errors

[Mark K. M. <mar...@la...>]

Oh, well wait ... I just noticed that the block reported in the error =
(58605129) is the last block of my raw disk image.  So I'm no longer =
concerned it's missing information in the string extraction. ;)


-----Original Message-----
From: Brian Carrier [mailto:ca...@sl...]
Sent: Thu 5/25/2006 7:46 AM
To: Mark K. Murdock
Cc: sle...@li...
Subject: Re: [sleuthkit-users] dls rawfs_block_walk errors
=20
What is the size (in bytes) of the file  you are reading?  I guess =20
this error could occur if your file is not a multiple of 512-bytes.  =20
Did you import the file image as a rawfs?

brian



On May 25, 2006, at 12:08 AM, Mark K. Murdock wrote:

> Hi all,
>
> I'm using Sleuthkit 2.03 and Autopsy 2.06 on Debian Linux (Sarge).  =20
> While extracting Unicode strings from an image, dls threw the =20
> following error:
>
> /usr/local/sleuthkit/bin/dls: rawfs_block_walk: Error reading block =20
> at 58605129: Success
>
> It did the same thing during an ASCII string extraction, but I =20
> didn't note the exact error.  I checked the source (rawfs.c) and it =20
> looks like that error occurs when (surprise) there's a problem =20
> reading a block while iterating the blocks of the image.  I'm not =20
> sure exactly what the problem was, because I didn't rerun the dls =20
> command with the verbose option specified (I'm planning to, but =20
> it's time consuming and I haven't gotten to that yet).
>
> My questions are:  When it comes to extracting strings, is it =20
> important that a block read error be a fatal error?  Currently it =20
> stops the string extraction (because dls quits).  I was thinking of =20
> making a small change to the source to keep iterating the blocks =20
> past a read error based on a command argument (an "ignore read =20
> errors" type switch).  Am I just getting myself into trouble here, =20
> or does doing something like this make sense?
>
> Thanks,
> Mark
>