[sleuthkit-users] freebsd and icat bug

[neutrino n. <neu...@ho...>]

I have been doing tests that was meant to show that the tool "sorter" used 
on a common image will produce the same output independant of Operation 
System. However, when I ran "sorter" on a FreeBSD-5.2.1 systems it produce 
files that were different to other systems (solaris sparc/ redhat i386).

Comparing output files from the redhat system to what was produced on the 
FreeBSD system in a hex editor,  I found that the FreeBSD system always 
differs at the offset 0x3400. I ran "ktrace" (Kernel Trace) on the "sorter" 
command that I was using in FreeBSD. What I found was when "icat" was 
reading the target file, it got to a point where it switched from doing a 
direct read, to using lseek before a read statement.

Further investigation using a hex editor I found that the problem seems to 
be a miscalcuation on the lseek. It seems to skip 1024 bytes at offset 
0x3400.

I am not a programmer, and I have dont have the time to investigate to much 
further, but I thought I would report it. Having a quick look at the source, 
I was guessing the problem may be in the OFF_T macro. But I could easily be 
wrong.

_________________________________________________________________
Express yourself instantly with MSN Messenger! Download today it's FREE! 
http://messenger.msn.com/