Re: [sleuthkit-users] dls rawfs_block_walk errors

[Brian C. <ca...@sl...>]

Yea, the image size is not a multiple of 512 and the file system code 
makes that assumption.  So, the error occurred because it could not read 
a full 512 bytes from the final sector.  I'll look into changing it so 
that it better handles this situation.

brian


Mark K. Murdock wrote:
> The image size is 30005826468 bytes.  I imported it as a raw drive 
> image.  It was previously NTFS, but was formatted and then a small (2 
> GB) FAT32 filesystem was created and a new operating system was 
> installed in it. 
> 
> So, in the "Select a volume to analyze or add a new image file" screen I 
> see:
> 
> disk    image-QWUF12CCHU-copy.dd-disk   raw     details
> C:/     image-QWUF12CCHU-copy.dd-63-4160834     fat32   details
> 
> Mark
> 
> 
> -----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
> 
> What is the size (in bytes) of the file  you are reading?  I guess 
> this error could occur if your file is not a multiple of 512-bytes.  
> 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).  
>  > While extracting Unicode strings from an image, dls threw the 
>  > following error:
>  >
>  > /usr/local/sleuthkit/bin/dls: rawfs_block_walk: Error reading block 
>  > at 58605129: Success
>  >
>  > It did the same thing during an ASCII string extraction, but I 
>  > didn't note the exact error.  I checked the source (rawfs.c) and it 
>  > looks like that error occurs when (surprise) there's a problem 
>  > reading a block while iterating the blocks of the image.  I'm not 
>  > sure exactly what the problem was, because I didn't rerun the dls 
>  > command with the verbose option specified (I'm planning to, but 
>  > it's time consuming and I haven't gotten to that yet).
>  >
>  > My questions are:  When it comes to extracting strings, is it 
>  > important that a block read error be a fatal error?  Currently it 
>  > stops the string extraction (because dls quits).  I was thinking of 
>  > making a small change to the source to keep iterating the blocks 
>  > past a read error based on a command argument (an "ignore read 
>  > errors" type switch).  Am I just getting myself into trouble here, 
>  > or does doing something like this make sense?
>  >
>  > Thanks,
>  > Mark
>  >
> 
>