sleuthkit-developers — A list to discuss development of new features of The Sleuth Kit and Autopsy

Re: [sleuthkit-developers] fiwalk build failure on Windows MingW

[Eamonn S. <ea...@ya...>]

I ended up downloading and installing libregex from http://sourceforge.net/projects/mingw/files/MSYS/Base/regex/regex-1.20090805-2/




----- Original Message -----
From: Rob Joyce <rj...@at...>
To: 'Eamonn Saunders' <ea...@ya...>; sle...@li...
Cc: 
Sent: Wednesday, April 24, 2013 2:47 PM
Subject: RE: [sleuthkit-developers] fiwalk build failure on Windows MingW

Thanks!  That fixes the problems in fiwalk.cpp, modulo a TSK_TCHAR* warning. 
(It required a little work to coax autotools to work again.  Also, my copy 
of pthreads for Windows [pthread.h, specifically] behaves badly when 
HAVE_CONFIG_H=1, but I can work around that.)

You're right, now arff.cpp wants regex.h, which it can't find.

_Rob


-----Original Message-----
From: Eamonn Saunders [mailto:ea...@ya...]
Sent: Wednesday, April 24, 2013 1:09 PM
To: Rob Joyce; sle...@li...
Subject: Re: [sleuthkit-developers] fiwalk build failure on Windows MingW

Hi Rob,
   I ran into similar issues last week. I've just pushed changes to master 
that should allow you to get past the compilation issues you are seeing.
Note that you will still probably run into a problem when the build process 
attempts to link fiwalk. To get around that I had to install libregex and 
add -lregex to the LIBS in tools/fiwalk\src\Makefile. Let me know if you 
need more details.

Eamonn



________________________________
From: Rob Joyce <rj...@at...>
To: sle...@li...
Sent: Wednesday, April 24, 2013 11:27 AM
Subject: [sleuthkit-developers] fiwalk build failure on Windows MingW



I'm building TSK on Windows using mingw/msys.  It works just fine until it 
gets to fiwalk.  (I’m not actually planning to use fiwalk, but that stops 
the TSK build in its tracks.)

It looks like the fiwalk source code is Windows-aware; any ideas?

This is g++ v4.5.2 and the current Github master (as of this morning, 
407bfa754f).  configure finds pthreads just fine.

Thanks,
_Rob


[…]
make[2]: Entering directory `/tmp/sleuthkit-master/tools/fiwalk'
Making all in src
make[3]: Entering directory `/tmp/sleuthkit-master/tools/fiwalk/src'
g++ -DHAVE_CONFIG_H -I. -I../../../tsk3  -I../../.. -Wall   -g -O2 -MT 
fiwalk.o -MD -MP -MF .deps/fiwalk.Tpo -c -o fiwalk.o fiwalk.cpp
In file included from fiwalk.cpp:39:0:
fiwalk.h:164:0: warning: "F_OK" redefined
c:\mingw\bin\../lib/gcc/mingw32/4.5.2/../../../../include/io.h:322:0: note: 
this is the location of the previous definition
fiwalk.h:165:0: warning: "W_OK" redefined
c:\mingw\bin\../lib/gcc/mingw32/4.5.2/../../../../include/io.h:326:0: note: 
this is the location of the previous definition
fiwalk.h:166:0: warning: "R_OK" redefined
c:\mingw\bin\../lib/gcc/mingw32/4.5.2/../../../../include/io.h:327:0: note: 
this is the location of the previous definition
In file included from fiwalk.h:99:0,
                 from fiwalk.cpp:39:
dfxml.h:96:5: error: 'pthread_mutex_t' does not name a type
dfxml.h: In copy constructor 'xml::xml(const xml&)':
dfxml.h:87:2: error: class 'xml' does not have any field named 'M'
fiwalk.cpp: In function 'int main(int, char* const*)':
fiwalk.cpp:500:13: error: cannot convert 'TSK_TCHAR*' to 'const char*' in 
assignment
fiwalk.cpp:523:13: error: cannot convert 'TSK_TCHAR*' to 'const char*' in 
assignment
fiwalk.cpp:532:29: error: no matching function for call to 
'std::basic_string<char>::basic_string(TSK_TCHAR*&)'
c:\mingw\bin\../lib/gcc/mingw32/4.5.2/include/c++/bits/basic_string.tcc:219:5: 
note: candidates are: std::basic_string<_CharT, _Traits, 
_Alloc>::basic_string(std::basic_string<_CharT, _Traits, _Alloc>::size_type, 
_CharT, const _Alloc&) [with _CharT = char, _Traits = 
std::char_traits<char>, _Alloc = std::allocator<char>, 
std::basic_string<_CharT, _Traits, _Alloc>::size_type = unsigned int]
c:\mingw\bin\../lib/gcc/mingw32/4.5.2/include/c++/bits/basic_string.tcc:212:5: 
note:                 std::basic_string<_CharT, _Traits, 
_Alloc>::basic_string(const _CharT*, const _Alloc&) [with _CharT = char, 
_Traits = std::char_traits<char>, _Alloc = std::allocator<char>]
c:\mingw\bin\../lib/gcc/mingw32/4.5.2/include/c++/bits/basic_string.tcc:205:5: 
note:                 std::basic_string<_CharT, _Traits, 
_Alloc>::basic_string(const _CharT*, std::basic_string<_CharT, _Traits, 
_Alloc>::size_type, const _Alloc&) [with _CharT = char, _Traits = 
std::char_traits<char>, _Alloc = std::allocator<char>, 
std::basic_string<_CharT, _Traits, _Alloc>::size_type = unsigned int]
c:\mingw\bin\../lib/gcc/mingw32/4.5.2/include/c++/bits/basic_string.tcc:193:5: 
note:                 std::basic_string<_CharT, _Traits, 
_Alloc>::basic_string(const std::basic_string<_CharT, _Traits, _Alloc>&, 
std::basic_string<_CharT, _Traits, _Alloc>::size_type, 
std::basic_string<_CharT, _Traits, _Alloc>::size_type, const _Alloc&) [with 
_CharT = char, _Traits = std::char_traits<char>, _Alloc = 
std::allocator<char>, std::basic_string<_CharT, _Traits, _Alloc> = 
std::basic_string<char>, std::basic_string<_CharT, _Traits, 
_Alloc>::size_type = unsigned int]
c:\mingw\bin\../lib/gcc/mingw32/4.5.2/include/c++/bits/basic_string.tcc:183:5: 
note:                 std::basic_string<_CharT, _Traits, 
_Alloc>::basic_string(const std::basic_string<_CharT, _Traits, _Alloc>&, 
std::basic_string<_CharT, _Traits, _Alloc>::size_type, 
std::basic_string<_CharT, _Traits, _Alloc>::size_type) [with _CharT = char, 
_Traits = std::char_traits<char>, _Alloc = std::allocator<char>, 
std::basic_string<_CharT, _Traits, _Alloc> = std::basic_string<char>, 
std::basic_string<_CharT, _Traits, _Alloc>::size_type = unsigned int]
c:\mingw\bin\../lib/gcc/mingw32/4.5.2/include/c++/bits/basic_string.tcc:169:5: 
note:                 std::basic_string<_CharT, _Traits, 
_Alloc>::basic_string(const std::basic_string<_CharT, _Traits, _Alloc>&) 
[with _CharT = char, _Traits = std::char_traits<char>, _Alloc = 
std::allocator<char>, std::basic_string<_CharT, _Traits, _Alloc> = 
std::basic_string<char>]
c:\mingw\bin\../lib/gcc/mingw32/4.5.2/include/c++/bits/basic_string.tcc:177:5: 
note:                 std::basic_string<_CharT, _Traits, 
_Alloc>::basic_string(const _Alloc&) [with _CharT = char, _Traits = 
std::char_traits<char>, _Alloc = std::allocator<char>]
c:\mingw\bin\../lib/gcc/mingw32/4.5.2/include/c++/bits/basic_string.h:423:7: 
note:                 std::basic_string<_CharT, _Traits, 
_Alloc>::basic_string() [with _CharT = char, _Traits = 
std::char_traits<char>, _Alloc = std::allocator<char>]
fiwalk.cpp:542:16: error: cannot convert 'TSK_TCHAR*' to 'const char*' in 
assignment
fiwalk.cpp:550:17: error: cannot convert 'TSK_TCHAR*' to 'const char*' in 
assignment
fiwalk.cpp:556:27: error: 'convert' was not declared in this scope
fiwalk.cpp:567:60: warning: format '%s' expects type 'char*', but argument 3 
has type 'TSK_TCHAR*'
fiwalk.cpp:581:31: error: cannot convert 'TSK_TCHAR* const' to 'const char*' 
in initialization
fiwalk.cpp:724:68: error: cannot convert 'TSK_TCHAR* const*' to 'char* 
const*' for argument '2' to 'int process_image_file(int, char* const*, const 
char*, u_int)'
fiwalk.cpp:727:53: error: cannot convert 'TSK_TCHAR* const*' to 'char* 
const*' for argument '2' to 'int process_image_file(int, char* const*, const 
char*, u_int)'
fiwalk.cpp:474:8: warning: unused variable 'argv_0'
make[3]: *** [fiwalk.o] Error 1
make[3]: Leaving directory `/tmp/sleuthkit-master/tools/fiwalk/src'
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory `/tmp/sleuthkit-master/tools/fiwalk'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/tmp/sleuthkit-master/tools'
make: *** [all-recursive] Error 1
------------------------------------------------------------------------------
Try New Relic Now & We'll Send You this Cool Shirt
New Relic is the only SaaS-based application performance monitoring service
that delivers powerful full stack analytics. Optimize and monitor your
browser, app, & servers with just a few lines of code. Try New Relic
and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr
_______________________________________________
sleuthkit-developers mailing list
sle...@li...
https://lists.sourceforge.net/lists/listinfo/sleuthkit-developers

Re: [sleuthkit-developers] fiwalk build failure on Windows MingW

[Rob J. <rj...@at...>]

Thanks!  That fixes the problems in fiwalk.cpp, modulo a TSK_TCHAR* warning. 
(It required a little work to coax autotools to work again.  Also, my copy 
of pthreads for Windows [pthread.h, specifically] behaves badly when 
HAVE_CONFIG_H=1, but I can work around that.)

You're right, now arff.cpp wants regex.h, which it can't find.

_Rob


-----Original Message-----
From: Eamonn Saunders [mailto:ea...@ya...]
Sent: Wednesday, April 24, 2013 1:09 PM
To: Rob Joyce; sle...@li...
Subject: Re: [sleuthkit-developers] fiwalk build failure on Windows MingW

Hi Rob,
   I ran into similar issues last week. I've just pushed changes to master 
that should allow you to get past the compilation issues you are seeing.
Note that you will still probably run into a problem when the build process 
attempts to link fiwalk. To get around that I had to install libregex and 
add -lregex to the LIBS in tools/fiwalk\src\Makefile. Let me know if you 
need more details.

Eamonn



________________________________
 From: Rob Joyce <rj...@at...>
To: sle...@li...
Sent: Wednesday, April 24, 2013 11:27 AM
Subject: [sleuthkit-developers] fiwalk build failure on Windows MingW



I'm building TSK on Windows using mingw/msys.  It works just fine until it 
gets to fiwalk.  (I’m not actually planning to use fiwalk, but that stops 
the TSK build in its tracks.)

It looks like the fiwalk source code is Windows-aware; any ideas?

This is g++ v4.5.2 and the current Github master (as of this morning, 
407bfa754f).  configure finds pthreads just fine.

Thanks,
_Rob


[…]
make[2]: Entering directory `/tmp/sleuthkit-master/tools/fiwalk'
Making all in src
make[3]: Entering directory `/tmp/sleuthkit-master/tools/fiwalk/src'
g++ -DHAVE_CONFIG_H -I. -I../../../tsk3  -I../../.. -Wall   -g -O2 -MT 
fiwalk.o -MD -MP -MF .deps/fiwalk.Tpo -c -o fiwalk.o fiwalk.cpp
In file included from fiwalk.cpp:39:0:
fiwalk.h:164:0: warning: "F_OK" redefined
c:\mingw\bin\../lib/gcc/mingw32/4.5.2/../../../../include/io.h:322:0: note: 
this is the location of the previous definition
fiwalk.h:165:0: warning: "W_OK" redefined
c:\mingw\bin\../lib/gcc/mingw32/4.5.2/../../../../include/io.h:326:0: note: 
this is the location of the previous definition
fiwalk.h:166:0: warning: "R_OK" redefined
c:\mingw\bin\../lib/gcc/mingw32/4.5.2/../../../../include/io.h:327:0: note: 
this is the location of the previous definition
In file included from fiwalk.h:99:0,
                 from fiwalk.cpp:39:
dfxml.h:96:5: error: 'pthread_mutex_t' does not name a type
dfxml.h: In copy constructor 'xml::xml(const xml&)':
dfxml.h:87:2: error: class 'xml' does not have any field named 'M'
fiwalk.cpp: In function 'int main(int, char* const*)':
fiwalk.cpp:500:13: error: cannot convert 'TSK_TCHAR*' to 'const char*' in 
assignment
fiwalk.cpp:523:13: error: cannot convert 'TSK_TCHAR*' to 'const char*' in 
assignment
fiwalk.cpp:532:29: error: no matching function for call to 
'std::basic_string<char>::basic_string(TSK_TCHAR*&)'
c:\mingw\bin\../lib/gcc/mingw32/4.5.2/include/c++/bits/basic_string.tcc:219:5: 
note: candidates are: std::basic_string<_CharT, _Traits, 
_Alloc>::basic_string(std::basic_string<_CharT, _Traits, _Alloc>::size_type, 
_CharT, const _Alloc&) [with _CharT = char, _Traits = 
std::char_traits<char>, _Alloc = std::allocator<char>, 
std::basic_string<_CharT, _Traits, _Alloc>::size_type = unsigned int]
c:\mingw\bin\../lib/gcc/mingw32/4.5.2/include/c++/bits/basic_string.tcc:212:5: 
note:                 std::basic_string<_CharT, _Traits, 
_Alloc>::basic_string(const _CharT*, const _Alloc&) [with _CharT = char, 
_Traits = std::char_traits<char>, _Alloc = std::allocator<char>]
c:\mingw\bin\../lib/gcc/mingw32/4.5.2/include/c++/bits/basic_string.tcc:205:5: 
note:                 std::basic_string<_CharT, _Traits, 
_Alloc>::basic_string(const _CharT*, std::basic_string<_CharT, _Traits, 
_Alloc>::size_type, const _Alloc&) [with _CharT = char, _Traits = 
std::char_traits<char>, _Alloc = std::allocator<char>, 
std::basic_string<_CharT, _Traits, _Alloc>::size_type = unsigned int]
c:\mingw\bin\../lib/gcc/mingw32/4.5.2/include/c++/bits/basic_string.tcc:193:5: 
note:                 std::basic_string<_CharT, _Traits, 
_Alloc>::basic_string(const std::basic_string<_CharT, _Traits, _Alloc>&, 
std::basic_string<_CharT, _Traits, _Alloc>::size_type, 
std::basic_string<_CharT, _Traits, _Alloc>::size_type, const _Alloc&) [with 
_CharT = char, _Traits = std::char_traits<char>, _Alloc = 
std::allocator<char>, std::basic_string<_CharT, _Traits, _Alloc> = 
std::basic_string<char>, std::basic_string<_CharT, _Traits, 
_Alloc>::size_type = unsigned int]
c:\mingw\bin\../lib/gcc/mingw32/4.5.2/include/c++/bits/basic_string.tcc:183:5: 
note:                 std::basic_string<_CharT, _Traits, 
_Alloc>::basic_string(const std::basic_string<_CharT, _Traits, _Alloc>&, 
std::basic_string<_CharT, _Traits, _Alloc>::size_type, 
std::basic_string<_CharT, _Traits, _Alloc>::size_type) [with _CharT = char, 
_Traits = std::char_traits<char>, _Alloc = std::allocator<char>, 
std::basic_string<_CharT, _Traits, _Alloc> = std::basic_string<char>, 
std::basic_string<_CharT, _Traits, _Alloc>::size_type = unsigned int]
c:\mingw\bin\../lib/gcc/mingw32/4.5.2/include/c++/bits/basic_string.tcc:169:5: 
note:                 std::basic_string<_CharT, _Traits, 
_Alloc>::basic_string(const std::basic_string<_CharT, _Traits, _Alloc>&) 
[with _CharT = char, _Traits = std::char_traits<char>, _Alloc = 
std::allocator<char>, std::basic_string<_CharT, _Traits, _Alloc> = 
std::basic_string<char>]
c:\mingw\bin\../lib/gcc/mingw32/4.5.2/include/c++/bits/basic_string.tcc:177:5: 
note:                 std::basic_string<_CharT, _Traits, 
_Alloc>::basic_string(const _Alloc&) [with _CharT = char, _Traits = 
std::char_traits<char>, _Alloc = std::allocator<char>]
c:\mingw\bin\../lib/gcc/mingw32/4.5.2/include/c++/bits/basic_string.h:423:7: 
note:                 std::basic_string<_CharT, _Traits, 
_Alloc>::basic_string() [with _CharT = char, _Traits = 
std::char_traits<char>, _Alloc = std::allocator<char>]
fiwalk.cpp:542:16: error: cannot convert 'TSK_TCHAR*' to 'const char*' in 
assignment
fiwalk.cpp:550:17: error: cannot convert 'TSK_TCHAR*' to 'const char*' in 
assignment
fiwalk.cpp:556:27: error: 'convert' was not declared in this scope
fiwalk.cpp:567:60: warning: format '%s' expects type 'char*', but argument 3 
has type 'TSK_TCHAR*'
fiwalk.cpp:581:31: error: cannot convert 'TSK_TCHAR* const' to 'const char*' 
in initialization
fiwalk.cpp:724:68: error: cannot convert 'TSK_TCHAR* const*' to 'char* 
const*' for argument '2' to 'int process_image_file(int, char* const*, const 
char*, u_int)'
fiwalk.cpp:727:53: error: cannot convert 'TSK_TCHAR* const*' to 'char* 
const*' for argument '2' to 'int process_image_file(int, char* const*, const 
char*, u_int)'
fiwalk.cpp:474:8: warning: unused variable 'argv_0'
make[3]: *** [fiwalk.o] Error 1
make[3]: Leaving directory `/tmp/sleuthkit-master/tools/fiwalk/src'
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory `/tmp/sleuthkit-master/tools/fiwalk'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/tmp/sleuthkit-master/tools'
make: *** [all-recursive] Error 1
------------------------------------------------------------------------------
Try New Relic Now & We'll Send You this Cool Shirt
New Relic is the only SaaS-based application performance monitoring service
that delivers powerful full stack analytics. Optimize and monitor your
browser, app, & servers with just a few lines of code. Try New Relic
and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr
_______________________________________________
sleuthkit-developers mailing list
sle...@li...
https://lists.sourceforge.net/lists/listinfo/sleuthkit-developers

Re: [sleuthkit-developers] fiwalk build failure on Windows MingW

[Eamonn S. <ea...@ya...>]

Hi Rob,
   I ran into similar issues last week. I've just pushed changes to master that should allow you to get past the compilation issues you are seeing.
Note that you will still probably run into a problem when the build process attempts to link fiwalk. To get around that I had to install libregex and add -lregex to the LIBS in tools/fiwalk\src\Makefile. Let me know if you need more details.

Eamonn



________________________________
 From: Rob Joyce <rj...@at...>
To: sle...@li... 
Sent: Wednesday, April 24, 2013 11:27 AM
Subject: [sleuthkit-developers] fiwalk build failure on Windows MingW
 


I'm building TSK on Windows using mingw/msys.  It works just fine until it gets to fiwalk.  (I’m not actually planning to use fiwalk, but that stops the TSK build in its tracks.)
 
It looks like the fiwalk source code is Windows-aware; any ideas?
 
This is g++ v4.5.2 and the current Github master (as of this morning, 407bfa754f).  configure finds pthreads just fine.
 
Thanks,
_Rob
 
 
[…]
make[2]: Entering directory `/tmp/sleuthkit-master/tools/fiwalk'
Making all in src
make[3]: Entering directory `/tmp/sleuthkit-master/tools/fiwalk/src'
g++ -DHAVE_CONFIG_H -I. -I../../../tsk3  -I../../.. -Wall   -g -O2 -MT fiwalk.o -MD -MP -MF .deps/fiwalk.Tpo -c -o fiwalk.o fiwalk.cpp
In file included from fiwalk.cpp:39:0:
fiwalk.h:164:0: warning: "F_OK" redefined
c:\mingw\bin\../lib/gcc/mingw32/4.5.2/../../../../include/io.h:322:0: note: this is the location of the previous definition
fiwalk.h:165:0: warning: "W_OK" redefined
c:\mingw\bin\../lib/gcc/mingw32/4.5.2/../../../../include/io.h:326:0: note: this is the location of the previous definition
fiwalk.h:166:0: warning: "R_OK" redefined
c:\mingw\bin\../lib/gcc/mingw32/4.5.2/../../../../include/io.h:327:0: note: this is the location of the previous definition
In file included from fiwalk.h:99:0,
                 from fiwalk.cpp:39:
dfxml.h:96:5: error: 'pthread_mutex_t' does not name a type
dfxml.h: In copy constructor 'xml::xml(const xml&)':
dfxml.h:87:2: error: class 'xml' does not have any field named 'M'
fiwalk.cpp: In function 'int main(int, char* const*)':
fiwalk.cpp:500:13: error: cannot convert 'TSK_TCHAR*' to 'const char*' in assignment
fiwalk.cpp:523:13: error: cannot convert 'TSK_TCHAR*' to 'const char*' in assignment
fiwalk.cpp:532:29: error: no matching function for call to 'std::basic_string<char>::basic_string(TSK_TCHAR*&)'
c:\mingw\bin\../lib/gcc/mingw32/4.5.2/include/c++/bits/basic_string.tcc:219:5: note: candidates are: std::basic_string<_CharT, _Traits, _Alloc>::basic_string(std::basic_string<_CharT, _Traits, _Alloc>::size_type, _CharT, const _Alloc&) [with _CharT = char, _Traits = std::char_traits<char>, _Alloc = std::allocator<char>, std::basic_string<_CharT, _Traits, _Alloc>::size_type = unsigned int]
c:\mingw\bin\../lib/gcc/mingw32/4.5.2/include/c++/bits/basic_string.tcc:212:5: note:                 std::basic_string<_CharT, _Traits, _Alloc>::basic_string(const _CharT*, const _Alloc&) [with _CharT = char, _Traits = std::char_traits<char>, _Alloc = std::allocator<char>]
c:\mingw\bin\../lib/gcc/mingw32/4.5.2/include/c++/bits/basic_string.tcc:205:5: note:                 std::basic_string<_CharT, _Traits, _Alloc>::basic_string(const _CharT*, std::basic_string<_CharT, _Traits, _Alloc>::size_type, const _Alloc&) [with _CharT = char, _Traits = std::char_traits<char>, _Alloc = std::allocator<char>, std::basic_string<_CharT, _Traits, _Alloc>::size_type = unsigned int]
c:\mingw\bin\../lib/gcc/mingw32/4.5.2/include/c++/bits/basic_string.tcc:193:5: note:                 std::basic_string<_CharT, _Traits, _Alloc>::basic_string(const std::basic_string<_CharT, _Traits, _Alloc>&, std::basic_string<_CharT, _Traits, _Alloc>::size_type, std::basic_string<_CharT, _Traits, _Alloc>::size_type, const _Alloc&) [with _CharT = char, _Traits = std::char_traits<char>, _Alloc = std::allocator<char>, std::basic_string<_CharT, _Traits, _Alloc> = std::basic_string<char>, std::basic_string<_CharT, _Traits, _Alloc>::size_type = unsigned int]
c:\mingw\bin\../lib/gcc/mingw32/4.5.2/include/c++/bits/basic_string.tcc:183:5: note:                 std::basic_string<_CharT, _Traits, _Alloc>::basic_string(const std::basic_string<_CharT, _Traits, _Alloc>&, std::basic_string<_CharT, _Traits, _Alloc>::size_type, std::basic_string<_CharT, _Traits, _Alloc>::size_type) [with _CharT = char, _Traits = std::char_traits<char>, _Alloc = std::allocator<char>, std::basic_string<_CharT, _Traits, _Alloc> = std::basic_string<char>, std::basic_string<_CharT, _Traits, _Alloc>::size_type = unsigned int]
c:\mingw\bin\../lib/gcc/mingw32/4.5.2/include/c++/bits/basic_string.tcc:169:5: note:                 std::basic_string<_CharT, _Traits, _Alloc>::basic_string(const std::basic_string<_CharT, _Traits, _Alloc>&) [with _CharT = char, _Traits = std::char_traits<char>, _Alloc = std::allocator<char>, std::basic_string<_CharT, _Traits, _Alloc> = std::basic_string<char>]
c:\mingw\bin\../lib/gcc/mingw32/4.5.2/include/c++/bits/basic_string.tcc:177:5: note:                 std::basic_string<_CharT, _Traits, _Alloc>::basic_string(const _Alloc&) [with _CharT = char, _Traits = std::char_traits<char>, _Alloc = std::allocator<char>]
c:\mingw\bin\../lib/gcc/mingw32/4.5.2/include/c++/bits/basic_string.h:423:7: note:                 std::basic_string<_CharT, _Traits, _Alloc>::basic_string() [with _CharT = char, _Traits = std::char_traits<char>, _Alloc = std::allocator<char>]
fiwalk.cpp:542:16: error: cannot convert 'TSK_TCHAR*' to 'const char*' in assignment
fiwalk.cpp:550:17: error: cannot convert 'TSK_TCHAR*' to 'const char*' in assignment
fiwalk.cpp:556:27: error: 'convert' was not declared in this scope
fiwalk.cpp:567:60: warning: format '%s' expects type 'char*', but argument 3 has type 'TSK_TCHAR*'
fiwalk.cpp:581:31: error: cannot convert 'TSK_TCHAR* const' to 'const char*' in initialization
fiwalk.cpp:724:68: error: cannot convert 'TSK_TCHAR* const*' to 'char* const*' for argument '2' to 'int process_image_file(int, char* const*, const char*, u_int)'
fiwalk.cpp:727:53: error: cannot convert 'TSK_TCHAR* const*' to 'char* const*' for argument '2' to 'int process_image_file(int, char* const*, const char*, u_int)'
fiwalk.cpp:474:8: warning: unused variable 'argv_0'
make[3]: *** [fiwalk.o] Error 1
make[3]: Leaving directory `/tmp/sleuthkit-master/tools/fiwalk/src'
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory `/tmp/sleuthkit-master/tools/fiwalk'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/tmp/sleuthkit-master/tools'
make: *** [all-recursive] Error 1
------------------------------------------------------------------------------
Try New Relic Now & We'll Send You this Cool Shirt
New Relic is the only SaaS-based application performance monitoring service 
that delivers powerful full stack analytics. Optimize and monitor your
browser, app, & servers with just a few lines of code. Try New Relic
and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr
_______________________________________________
sleuthkit-developers mailing list
sle...@li...
https://lists.sourceforge.net/lists/listinfo/sleuthkit-developers

[sleuthkit-developers] fiwalk build failure on Windows MingW

[Rob J. <rj...@at...>]

I'm building TSK on Windows using mingw/msys.  It works just fine until it 
gets to fiwalk.  (I’m not actually planning to use fiwalk, but that stops 
the TSK build in its tracks.)



It looks like the fiwalk source code is Windows-aware; any ideas?



This is g++ v4.5.2 and the current Github master (as of this morning, 
407bfa754f).  configure finds pthreads just fine.



Thanks,

_Rob





[…]

make[2]: Entering directory `/tmp/sleuthkit-master/tools/fiwalk'

Making all in src

make[3]: Entering directory `/tmp/sleuthkit-master/tools/fiwalk/src'

g++ -DHAVE_CONFIG_H -I. -I../../../tsk3  -I../../.. -Wall   -g -O2 -MT 
fiwalk.o -MD -MP -MF .deps/fiwalk.Tpo -c -o fiwalk.o fiwalk.cpp

In file included from fiwalk.cpp:39:0:

fiwalk.h:164:0: warning: "F_OK" redefined

c:\mingw\bin\../lib/gcc/mingw32/4.5.2/../../../../include/io.h:322:0: note: 
this is the location of the previous definition

fiwalk.h:165:0: warning: "W_OK" redefined

c:\mingw\bin\../lib/gcc/mingw32/4.5.2/../../../../include/io.h:326:0: note: 
this is the location of the previous definition

fiwalk.h:166:0: warning: "R_OK" redefined

c:\mingw\bin\../lib/gcc/mingw32/4.5.2/../../../../include/io.h:327:0: note: 
this is the location of the previous definition

In file included from fiwalk.h:99:0,

                 from fiwalk.cpp:39:

dfxml.h:96:5: error: 'pthread_mutex_t' does not name a type

dfxml.h: In copy constructor 'xml::xml(const xml&)':

dfxml.h:87:2: error: class 'xml' does not have any field named 'M'

fiwalk.cpp: In function 'int main(int, char* const*)':

fiwalk.cpp:500:13: error: cannot convert 'TSK_TCHAR*' to 'const char*' in 
assignment

fiwalk.cpp:523:13: error: cannot convert 'TSK_TCHAR*' to 'const char*' in 
assignment

fiwalk.cpp:532:29: error: no matching function for call to 
'std::basic_string<char>::basic_string(TSK_TCHAR*&)'

c:\mingw\bin\../lib/gcc/mingw32/4.5.2/include/c++/bits/basic_string.tcc:219:5: 
note: candidates are: std::basic_string<_CharT, _Traits, 
_Alloc>::basic_string(std::basic_string<_CharT, _Traits, _Alloc>::size_type, 
_CharT, const _Alloc&) [with _CharT = char, _Traits = 
std::char_traits<char>, _Alloc = std::allocator<char>, 
std::basic_string<_CharT, _Traits, _Alloc>::size_type = unsigned int]

c:\mingw\bin\../lib/gcc/mingw32/4.5.2/include/c++/bits/basic_string.tcc:212:5: 
note:                 std::basic_string<_CharT, _Traits, 
_Alloc>::basic_string(const _CharT*, const _Alloc&) [with _CharT = char, 
_Traits = std::char_traits<char>, _Alloc = std::allocator<char>]

c:\mingw\bin\../lib/gcc/mingw32/4.5.2/include/c++/bits/basic_string.tcc:205:5: 
note:                 std::basic_string<_CharT, _Traits, 
_Alloc>::basic_string(const _CharT*, std::basic_string<_CharT, _Traits, 
_Alloc>::size_type, const _Alloc&) [with _CharT = char, _Traits = 
std::char_traits<char>, _Alloc = std::allocator<char>, 
std::basic_string<_CharT, _Traits, _Alloc>::size_type = unsigned int]

c:\mingw\bin\../lib/gcc/mingw32/4.5.2/include/c++/bits/basic_string.tcc:193:5: 
note:                 std::basic_string<_CharT, _Traits, 
_Alloc>::basic_string(const std::basic_string<_CharT, _Traits, _Alloc>&, 
std::basic_string<_CharT, _Traits, _Alloc>::size_type, 
std::basic_string<_CharT, _Traits, _Alloc>::size_type, const _Alloc&) [with 
_CharT = char, _Traits = std::char_traits<char>, _Alloc = 
std::allocator<char>, std::basic_string<_CharT, _Traits, _Alloc> = 
std::basic_string<char>, std::basic_string<_CharT, _Traits, 
_Alloc>::size_type = unsigned int]

c:\mingw\bin\../lib/gcc/mingw32/4.5.2/include/c++/bits/basic_string.tcc:183:5: 
note:                 std::basic_string<_CharT, _Traits, 
_Alloc>::basic_string(const std::basic_string<_CharT, _Traits, _Alloc>&, 
std::basic_string<_CharT, _Traits, _Alloc>::size_type, 
std::basic_string<_CharT, _Traits, _Alloc>::size_type) [with _CharT = char, 
_Traits = std::char_traits<char>, _Alloc = std::allocator<char>, 
std::basic_string<_CharT, _Traits, _Alloc> = std::basic_string<char>, 
std::basic_string<_CharT, _Traits, _Alloc>::size_type = unsigned int]

c:\mingw\bin\../lib/gcc/mingw32/4.5.2/include/c++/bits/basic_string.tcc:169:5: 
note:                 std::basic_string<_CharT, _Traits, 
_Alloc>::basic_string(const std::basic_string<_CharT, _Traits, _Alloc>&) 
[with _CharT = char, _Traits = std::char_traits<char>, _Alloc = 
std::allocator<char>, std::basic_string<_CharT, _Traits, _Alloc> = 
std::basic_string<char>]

c:\mingw\bin\../lib/gcc/mingw32/4.5.2/include/c++/bits/basic_string.tcc:177:5: 
note:                 std::basic_string<_CharT, _Traits, 
_Alloc>::basic_string(const _Alloc&) [with _CharT = char, _Traits = 
std::char_traits<char>, _Alloc = std::allocator<char>]

c:\mingw\bin\../lib/gcc/mingw32/4.5.2/include/c++/bits/basic_string.h:423:7: 
note:                 std::basic_string<_CharT, _Traits, 
_Alloc>::basic_string() [with _CharT = char, _Traits = 
std::char_traits<char>, _Alloc = std::allocator<char>]

fiwalk.cpp:542:16: error: cannot convert 'TSK_TCHAR*' to 'const char*' in 
assignment

fiwalk.cpp:550:17: error: cannot convert 'TSK_TCHAR*' to 'const char*' in 
assignment

fiwalk.cpp:556:27: error: 'convert' was not declared in this scope

fiwalk.cpp:567:60: warning: format '%s' expects type 'char*', but argument 3 
has type 'TSK_TCHAR*'

fiwalk.cpp:581:31: error: cannot convert 'TSK_TCHAR* const' to 'const char*' 
in initialization

fiwalk.cpp:724:68: error: cannot convert 'TSK_TCHAR* const*' to 'char* 
const*' for argument '2' to 'int process_image_file(int, char* const*, const 
char*, u_int)'

fiwalk.cpp:727:53: error: cannot convert 'TSK_TCHAR* const*' to 'char* 
const*' for argument '2' to 'int process_image_file(int, char* const*, const 
char*, u_int)'

fiwalk.cpp:474:8: warning: unused variable 'argv_0'

make[3]: *** [fiwalk.o] Error 1

make[3]: Leaving directory `/tmp/sleuthkit-master/tools/fiwalk/src'

make[2]: *** [all-recursive] Error 1

make[2]: Leaving directory `/tmp/sleuthkit-master/tools/fiwalk'

make[1]: *** [all-recursive] Error 1

make[1]: Leaving directory `/tmp/sleuthkit-master/tools'

make: *** [all-recursive] Error 1

[sleuthkit-developers] [ sleuthkit-Feature Requests-3608637 ] add reverse-order option for fls

[SourceForge.net <no...@so...>]

Feature Requests item #3608637, was opened at 2013-03-20 11:37
Message generated for change (Tracker Item Submitted) made by petiepooo
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=477892&aid=3608637&group_id=55685

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: File System
Group: None
Status: Open
Priority: 5
Private: No
Submitted By: Pete (petiepooo)
Assigned to: Nobody/Anonymous (nobody)
Summary: add reverse-order option for fls

Initial Comment:
Fls recurses into the filesystem nodes in alphabetic order.  On Windows systems, most of the forensically interesting files end up being in the Windows folder, toward the end of a recursive listing.  When capturing the file system listing over an extremely slow network link (think international iSCSI or multiple sshfs links), when using the recursive option, we are not able to see interesting inodes until the listing is nearly complete.

Of course, one could manually walk the tree of inodes to get to the desired directory, but over extremely high latency links, even a single directory can take minutes to complete.  And if a goal is a complete recursive listing, that's duplication of effort that is best avoided.

Giving us a reverse-order (-R?) option to simply reverse the alphabetic sort and retrieve them in the opposite order would get to the later directories earlier and allow icat to collect some files before a recursive fls is complete.  It would also allow one to splice together two overlapping partial captures if they're in different sort order.  Eg. first FLS output stops partway through (network/host disruption).  Start a second in reverse order, and once it reaches the point where the first one stopped, abort it and manually join the two.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=477892&aid=3608637&group_id=55685

[sleuthkit-developers] [ sleuthkit-Feature Requests-3547142 ] javac detection in beta 4.0

[SourceForge.net <no...@so...>]

Feature Requests item #3547142, was opened at 2012-07-21 22:50
Message generated for change (Comment added) made by jbmetz
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=477892&aid=3547142&group_id=55685

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Priority: 5
Private: No
Submitted By: Joachim Metz (jbmetz)
Assigned to: Nobody/Anonymous (nobody)
Summary: javac detection in beta 4.0

Initial Comment:
Small issue but on OSX the javac detecting in ./configure triggers a "Would you like to install javac" popup.
Can you add a configure option to disable (or preferable enable when necessary) the javac check.

----------------------------------------------------------------------

>Comment By: Joachim Metz (jbmetz)
Date: 2013-03-17 03:33

Message:
Patch against 20130317 pull of the github version.
Java is disabled by default --with-java will invoke autodetection of jdk.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=477892&aid=3547142&group_id=55685

Re: [sleuthkit-developers] fiwalk byte run options

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

Merged in.  Thanks.

On Feb 1, 2013, at 5:25 PM, Jon Stewart wrote:

> Opened it this afternoon.
> 
> 
> Jon
> 
> On Fri, Feb 1, 2013 at 5:23 PM, Brian Carrier <ca...@sl...> wrote:
>> Simson said he was fine with this.  Can you send a pull request?
>> 
>> On Jan 29, 2013, at 3:24 PM, Jon Stewart <jo...@li...> wrote:
>> 
>>> Howdy,
>>> 
>>> The trunk version of fiwalk has option "-g", which adds
>>> TSK_FS_FILE_WALK_FLAG_AONLY to the flags for calls to
>>> tsk_fs_file_walk(). However, it is currently a useless option because
>>> the only way to trigger tsk_fs_file_walk() is if
>>> content::need_file_walk() in content.cpp returns true. Here is
>>> content::need_file_walk():
>>> 
>>> bool content::need_file_walk()
>>> {
>>> return opt_md5 || opt_sha1 || opt_save || do_plugin || opt_magic
>>>     || opt_get_fragments;
>>> //      || opt_compute_sector_hashes;
>>> }
>>> 
>>> Any of the options "opt_md5 || opt_sha1 || opt_save || do_plugin ||
>>> opt_magic" require the file content to be meaningful. That leaves
>>> "opt_get_fragments". In trunk, opt_get_fragments is initialized to
>>> false and never assigned to again.
>>> 
>>> This patch on github initializes opt_get_fragments to true while
>>> keeping -g to control only whether the data is retrieved.
>>> Additionally, it adds "-b" to set opt_get_fragments to false and
>>> suppress byte runs from being printed:
>>> 
>>> https://github.com/jonstewart/sleuthkit/commit/bcdc5f7b1c1123c73009eea2b6cc6c6746e3bdc1
>>> 
>>> 
>>> However, both -g and -b only make if "opt_md5 || opt_sha1 || opt_save
>>> || do_plugin || opt_magic" is false.
>>> 
>>> My questions are:
>>> 
>>> 1. Does this change (setting opt_get_fragments to true by default,
>>> adding -b to disable it) make sense to folks?
>>> 
>>> 2. Does it make sense to add a check so that if (opt_md5 || opt_sha1
>>> || opt_save || do_plugin || opt_magic) is true, then "-g" is
>>> overridden and the content is always retrieved?
>>> 
>>> 
>>> cheers,
>>> 
>>> 
>>> Jon
>>> --
>>> Jon Stewart, Principal
>>> (646) 719-0317 | jo...@li... | Arlington, VA
>>> 
>>> ------------------------------------------------------------------------------
>>> Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS,
>>> MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current
>>> with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft
>>> MVPs and experts. ON SALE this month only -- learn more at:
>>> http://p.sf.net/sfu/learnnow-d2d
>>> _______________________________________________
>>> sleuthkit-developers mailing list
>>> sle...@li...
>>> https://lists.sourceforge.net/lists/listinfo/sleuthkit-developers
>> 
> 
> 
> 
> -- 
> Jon Stewart, Principal
> (646) 719-0317 | jo...@li... | Arlington, VA
> 
> ------------------------------------------------------------------------------
> Everyone hates slow websites. So do we.
> Make your web apps faster with AppDynamics
> Download AppDynamics Lite for free today:
> http://p.sf.net/sfu/appdyn_d2d_jan
> _______________________________________________
> sleuthkit-developers mailing list
> sle...@li...
> https://lists.sourceforge.net/lists/listinfo/sleuthkit-developers

Re: [sleuthkit-developers] fiwalk byte run options

[Jon S. <jo...@li...>]

Opened it this afternoon.


Jon

On Fri, Feb 1, 2013 at 5:23 PM, Brian Carrier <ca...@sl...> wrote:
> Simson said he was fine with this.  Can you send a pull request?
>
> On Jan 29, 2013, at 3:24 PM, Jon Stewart <jo...@li...> wrote:
>
>> Howdy,
>>
>> The trunk version of fiwalk has option "-g", which adds
>> TSK_FS_FILE_WALK_FLAG_AONLY to the flags for calls to
>> tsk_fs_file_walk(). However, it is currently a useless option because
>> the only way to trigger tsk_fs_file_walk() is if
>> content::need_file_walk() in content.cpp returns true. Here is
>> content::need_file_walk():
>>
>> bool content::need_file_walk()
>> {
>>  return opt_md5 || opt_sha1 || opt_save || do_plugin || opt_magic
>>      || opt_get_fragments;
>> //      || opt_compute_sector_hashes;
>> }
>>
>> Any of the options "opt_md5 || opt_sha1 || opt_save || do_plugin ||
>> opt_magic" require the file content to be meaningful. That leaves
>> "opt_get_fragments". In trunk, opt_get_fragments is initialized to
>> false and never assigned to again.
>>
>> This patch on github initializes opt_get_fragments to true while
>> keeping -g to control only whether the data is retrieved.
>> Additionally, it adds "-b" to set opt_get_fragments to false and
>> suppress byte runs from being printed:
>>
>>  https://github.com/jonstewart/sleuthkit/commit/bcdc5f7b1c1123c73009eea2b6cc6c6746e3bdc1
>>
>>
>> However, both -g and -b only make if "opt_md5 || opt_sha1 || opt_save
>> || do_plugin || opt_magic" is false.
>>
>> My questions are:
>>
>> 1. Does this change (setting opt_get_fragments to true by default,
>> adding -b to disable it) make sense to folks?
>>
>> 2. Does it make sense to add a check so that if (opt_md5 || opt_sha1
>> || opt_save || do_plugin || opt_magic) is true, then "-g" is
>> overridden and the content is always retrieved?
>>
>>
>> cheers,
>>
>>
>> Jon
>> --
>> Jon Stewart, Principal
>> (646) 719-0317 | jo...@li... | Arlington, VA
>>
>> ------------------------------------------------------------------------------
>> Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS,
>> MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current
>> with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft
>> MVPs and experts. ON SALE this month only -- learn more at:
>> http://p.sf.net/sfu/learnnow-d2d
>> _______________________________________________
>> sleuthkit-developers mailing list
>> sle...@li...
>> https://lists.sourceforge.net/lists/listinfo/sleuthkit-developers
>



-- 
Jon Stewart, Principal
(646) 719-0317 | jo...@li... | Arlington, VA

Re: [sleuthkit-developers] fiwalk byte run options

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

Simson said he was fine with this.  Can you send a pull request? 

On Jan 29, 2013, at 3:24 PM, Jon Stewart <jo...@li...> wrote:

> Howdy,
> 
> The trunk version of fiwalk has option "-g", which adds
> TSK_FS_FILE_WALK_FLAG_AONLY to the flags for calls to
> tsk_fs_file_walk(). However, it is currently a useless option because
> the only way to trigger tsk_fs_file_walk() is if
> content::need_file_walk() in content.cpp returns true. Here is
> content::need_file_walk():
> 
> bool content::need_file_walk()
> {
>  return opt_md5 || opt_sha1 || opt_save || do_plugin || opt_magic
>      || opt_get_fragments;
> //      || opt_compute_sector_hashes;
> }
> 
> Any of the options "opt_md5 || opt_sha1 || opt_save || do_plugin ||
> opt_magic" require the file content to be meaningful. That leaves
> "opt_get_fragments". In trunk, opt_get_fragments is initialized to
> false and never assigned to again.
> 
> This patch on github initializes opt_get_fragments to true while
> keeping -g to control only whether the data is retrieved.
> Additionally, it adds "-b" to set opt_get_fragments to false and
> suppress byte runs from being printed:
> 
>  https://github.com/jonstewart/sleuthkit/commit/bcdc5f7b1c1123c73009eea2b6cc6c6746e3bdc1
> 
> 
> However, both -g and -b only make if "opt_md5 || opt_sha1 || opt_save
> || do_plugin || opt_magic" is false.
> 
> My questions are:
> 
> 1. Does this change (setting opt_get_fragments to true by default,
> adding -b to disable it) make sense to folks?
> 
> 2. Does it make sense to add a check so that if (opt_md5 || opt_sha1
> || opt_save || do_plugin || opt_magic) is true, then "-g" is
> overridden and the content is always retrieved?
> 
> 
> cheers,
> 
> 
> Jon
> -- 
> Jon Stewart, Principal
> (646) 719-0317 | jo...@li... | Arlington, VA
> 
> ------------------------------------------------------------------------------
> Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS,
> MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current
> with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft
> MVPs and experts. ON SALE this month only -- learn more at:
> http://p.sf.net/sfu/learnnow-d2d
> _______________________________________________
> sleuthkit-developers mailing list
> sle...@li...
> https://lists.sourceforge.net/lists/listinfo/sleuthkit-developers

[sleuthkit-developers] [ sleuthkit-Feature Requests-3184431 ] full file path in DB

[SourceForge.net <no...@so...>]

Feature Requests item #3184431, was opened at 2011-02-16 19:40
Message generated for change (Settings changed) made by carrier
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=477892&aid=3184431&group_id=55685

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Auto
Group: None
>Status: Closed
Priority: 5
Private: No
Submitted By: Brian Carrier (carrier)
Assigned to: Nobody/Anonymous (nobody)
Summary: full file path in DB

Initial Comment:
John Lehr requested that the full file path be stored in SQLite instead of just the parent directory address. 

----------------------------------------------------------------------

Comment By: Brian Carrier (carrier)
Date: 2013-01-29 14:21

Message:
The full parent path is now in the framework and v2 schemas. 

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=477892&aid=3184431&group_id=55685

[sleuthkit-developers] [ sleuthkit-Feature Requests-3184431 ] full file path in DB

[SourceForge.net <no...@so...>]

Feature Requests item #3184431, was opened at 2011-02-16 19:40
Message generated for change (Comment added) made by carrier
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=477892&aid=3184431&group_id=55685

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Auto
Group: None
Status: Open
Priority: 5
Private: No
Submitted By: Brian Carrier (carrier)
Assigned to: Nobody/Anonymous (nobody)
Summary: full file path in DB

Initial Comment:
John Lehr requested that the full file path be stored in SQLite instead of just the parent directory address. 

----------------------------------------------------------------------

>Comment By: Brian Carrier (carrier)
Date: 2013-01-29 14:21

Message:
The full parent path is now in the framework and v2 schemas. 

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=477892&aid=3184431&group_id=55685

[sleuthkit-developers] [ sleuthkit-Feature Requests-3436562 ] New DB to support resident files

[SourceForge.net <no...@so...>]

Feature Requests item #3436562, was opened at 2011-11-11 07:46
Message generated for change (Comment added) made by carrier
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=477892&aid=3436562&group_id=55685

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Auto
Group: None
>Status: Closed
Priority: 5
Private: No
Submitted By: Brian Carrier (carrier)
Assigned to: Nobody/Anonymous (nobody)
Summary: New DB to support resident files

Initial Comment:
It would be nice if the new DB schema would allow queries to map resident files to their file.  fs_file_layout is byte-oriented, so this could work if TSK provided the specific byte-offset of resident files (a request that has come up a few times before). 

The challenge is that the same byte sequence would be in fs_file_layout twice.  Once for $MFT and another for the resident file...  This could be confusing.  But, it is also possible for there to be multiple overlapping carved files, so perhaps there isn't a requirement that fs_file_layout have only one entry for a given byte sequence. 

----------------------------------------------------------------------

>Comment By: Brian Carrier (carrier)
Date: 2013-01-29 14:20

Message:
Closed and added to a growing list of requirements for hte  next DB schema.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=477892&aid=3436562&group_id=55685

[sleuthkit-developers] [ sleuthkit-Bugs-3441760 ] Building TSK 3.2.3 without g++

[SourceForge.net <no...@so...>]

Bugs item #3441760, was opened at 2011-11-24 03:45
Message generated for change (Comment added) made by carrier
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=477889&aid=3441760&group_id=55685

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
>Status: Closed
Resolution: None
Priority: 5
Private: No
Submitted By: Joachim Metz (jbmetz)
Assigned to: Nobody/Anonymous (nobody)
Summary: Building TSK 3.2.3 without g++ 

Initial Comment:
Configure does not complain if g++ is missing.

Ubuntu 10.04.3 LTS

/usr/bin/ld: auto/.libs/libtskauto.a(auto.o): relocation R_X86_64_32S against `vtable for TskAuto' can not be used when making a shared object; recompile with -fPIC
auto/.libs/libtskauto.a(auto.o): could not read symbols: Bad value


----------------------------------------------------------------------

>Comment By: Brian Carrier (carrier)
Date: 2013-01-29 14:16

Message:
We have AC_PROG_CXX, which should check for G++. 

Closing this unless there is something else to be done.

----------------------------------------------------------------------

Comment By: Joachim Metz (jbmetz)
Date: 2011-11-24 03:54

Message:
The latter one seems to be introduced by an instable build tree caused by
running make without g++.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=477889&aid=3441760&group_id=55685

[sleuthkit-developers] [ sleuthkit-Bugs-3441763 ] Error in verbose output

[SourceForge.net <no...@so...>]

Bugs item #3441763, was opened at 2011-11-24 03:56
Message generated for change (Comment added) made by carrier
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=477889&aid=3441763&group_id=55685

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Private: No
Submitted By: Joachim Metz (jbmetz)
Assigned to: Nobody/Anonymous (nobody)
Summary: Error in verbose output

Initial Comment:
tsk3/fs/iso9660.c:2329

    if (tsk_verbose) {
        tsk_fprintf(stderr, "iso9660_open img_info: %lu"
            " ftype: %" PRIu8 " test: %" PRIu8 "\n", (uintptr_t) img_info,
            ftype, test);
    }

The %lu in this code should be %jd on Linux. Otherwise it prints an incorrect value on a 64-bit platform.


----------------------------------------------------------------------

>Comment By: Brian Carrier (carrier)
Date: 2013-01-29 14:12

Message:
[master 9d70763] Fixed some debug messages in iso9660 of memory pointers
that coudl be too big for data type in printf -- issue 3441763
 1 file changed, 20 insertions(+), 22 deletions(-)

A combination of removing some of the statements and changing them to
PRIu64 with needed casts. That seemed to be the safest cross platform
approach.

----------------------------------------------------------------------

Comment By: Joachim Metz (jbmetz)
Date: 2011-11-24 05:09

Message:
sk3/fs/ntfs_dent.c:1001

            rec_len =
                (uint32_t) (idxalloc_len - (uintptr_t) idxrec_p -
                (uintptr_t) idxalloc);

            if (tsk_verbose)
                tsk_fprintf(stderr,
                    "ntfs_dir_open_meta: Processing final index record
(len: %"
                    PRIu32 ")\n", rec_len);

calculation of rec_len seems to return a negative value

----------------------------------------------------------------------

Comment By: Joachim Metz (jbmetz)
Date: 2011-11-24 05:04

Message:
tsk3/fs/ntfs_dent.c:456

                "ntfs_proc_idxentry: Entry Details of %s: Str Len: %"
                PRIu16 "  Len to end after current: %" PRIu64
                "  flags: %x\n", fs_name->name, tsk_getu16(fs->endian,
                    a_idxe->strlen),
                (uint64_t) (endaddr_alloc - (uintptr_t) a_idxe -
                    tsk_getu16(fs->endian, a_idxe->idxlen)),
                fs_name->flags);

Please check the  %" PRIu64 " value calculation it seems to turn negative
on a 64-bit platform.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=477889&aid=3441763&group_id=55685

[sleuthkit-developers] [ sleuthkit-Bugs-3523019 ] More checks on FAT "." entries

[SourceForge.net <no...@so...>]

Bugs item #3523019, was opened at 2012-05-02 06:36
Message generated for change (Comment added) made by carrier
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=477889&aid=3523019&group_id=55685

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: File System Tools
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Private: No
Submitted By: Brian Carrier (carrier)
Assigned to: Nobody/Anonymous (nobody)
Summary: More checks on FAT "." entries

Initial Comment:
Currently, TSK does special things with any "." entry it finds in the directory.  We should limit this to only the first couple of entires in the directory.  Otherwise, someone could manually change the name of a file to be "." and its content would not be accessible. 


----------------------------------------------------------------------

>Comment By: Brian Carrier (carrier)
Date: 2013-01-29 13:28

Message:
Fixed with this pull request from timow.  Thanks.
https://github.com/sleuthkit/sleuthkit/pull/154

----------------------------------------------------------------------

Comment By: Timo Warns (timowpre)
Date: 2012-12-12 04:17

Message:
From aca201cb4a937709c055350101cdd36b01ce4b5b Mon Sep 17 00:00:00 2001
From: Timo Warns <wa...@pr...>
Date: Wed, 12 Dec 2012 11:52:19 +0100
Subject: [PATCH] limit special handling of files named "." and ".."

A file named "." or ".." shall only be specially handled if it is a
directory
and is among the first two directory entries. Otherwise, renaming a file to
"." or ".." could hide the file from TSK. Fixes CVE-2012-5619.
---
 tsk3/fs/fatfs_dent.cpp |    4 +++-
 1 files changed, 3 insertions(+), 1 deletions(-)

diff --git a/tsk3/fs/fatfs_dent.cpp b/tsk3/fs/fatfs_dent.cpp
index b76b9e3..aa0a4e2 100644
--- a/tsk3/fs/fatfs_dent.cpp
+++ b/tsk3/fs/fatfs_dent.cpp
@@ -439,7 +439,9 @@ static TSK_RETVAL_ENUM
             * slot in the cluster, but it needs to refer to the original
             * slot
             */
-            if (TSK_FS_ISDOT(fs_name->name)) {
+            if (TSK_FS_ISDOT(fs_name->name)
+                    && (fs_name->type == TSK_FS_NAME_TYPE_DIR)
+                    && idx < 2) {
                 if (fs_name->name[1] == '\0') {
                     fs_name->meta_addr =
                         a_fs_dir->fs_file->meta->addr;
-- 
1.7.2.5



----------------------------------------------------------------------

Comment By: Timo Warns (timowpre)
Date: 2012-12-12 04:16

Message:
The attached patch seems to fix the issue.

----------------------------------------------------------------------

Comment By: Timo Warns (timowpre)
Date: 2012-11-26 06:28

Message:
Here is a reproducer:

### create an empty image

$ dd if=/dev/zero of=empty.img bs=1M count=50
$ mkfs.vfat -F32 empty.img             


### create an image with FILE.txt

$ cp empty.img file.img
$ mount -o loop file.img /mnt/image/
$ echo "HELLO" > /mnt/image/FILE.TXT
$ umount /mnt/image/


### create an image with "." file (renamed from FILE.TXT)

$ xxd -p file.img | sed -e
's/46494c4520202020545854/2e20202020202020202020/' | xxd -r -p > dot.img


### use TSK

$ fls -V
The Sleuth Kit ver 4.0.1

$ fls -a empty.img
v/v 1612675:    $MBR
v/v 1612676:    $FAT1
v/v 1612677:    $FAT2
d/d 1612678:    $OrphanFiles

$ fls -a file.img
r/r 3:  FILE.TXT
v/v 1612675:    $MBR
v/v 1612676:    $FAT1
v/v 1612677:    $FAT2
d/d 1612678:    $OrphanFiles

$ fls -a dot.img
r/d 2:	.
v/v 1612675:	$MBR
v/v 1612676:	$FAT1
v/v 1612677:	$FAT2
d/d 1612678:	$OrphanFiles


----------------------------------------------------------------------

Comment By: Brian Carrier (carrier)
Date: 2012-11-26 06:22

Message:
Interesting. That side effect could also be because of the de-duping code
in TSK. It's strange in that report that entry 2 came up as r/d meaning
that it thought it was a file at the name level, but then mapped it to the
directory at the meta data level.


----------------------------------------------------------------------

Comment By: Timo Warns (timowpre)
Date: 2012-11-26 01:15

Message:
Note that this bug affects analyses of USB sticks that came in contact with
the Flame malware. On FAT file systems, Flame creates a file with short
name "HUB001.DAT"  and long name "." in the root directory (see
http://labs.bitdefender.com/2012/06/flame-the-story-of-leaked-data-carried-by-human-vector/).

TSK does not appropriately show such files (e.g., see
http://blog.crysys.hu/2012/06/flame-usb-dot-file-confirmed/).

If Flame writes its file to an empty USB stick, the file is the very first
entry of the root directory. Hence, a limitation of the "special things" to
the first couple of entries is not sufficient in this case.

----------------------------------------------------------------------

Comment By: Brian Carrier (carrier)
Date: 2012-05-02 06:37

Message:
Reported by Ilias Van Peer.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=477889&aid=3523019&group_id=55685

[sleuthkit-developers] fiwalk byte run options

[Jon S. <jo...@li...>]

Howdy,

The trunk version of fiwalk has option "-g", which adds
TSK_FS_FILE_WALK_FLAG_AONLY to the flags for calls to
tsk_fs_file_walk(). However, it is currently a useless option because
the only way to trigger tsk_fs_file_walk() is if
content::need_file_walk() in content.cpp returns true. Here is
content::need_file_walk():

bool content::need_file_walk()
{
  return opt_md5 || opt_sha1 || opt_save || do_plugin || opt_magic
      || opt_get_fragments;
//      || opt_compute_sector_hashes;
}

Any of the options "opt_md5 || opt_sha1 || opt_save || do_plugin ||
opt_magic" require the file content to be meaningful. That leaves
"opt_get_fragments". In trunk, opt_get_fragments is initialized to
false and never assigned to again.

This patch on github initializes opt_get_fragments to true while
keeping -g to control only whether the data is retrieved.
Additionally, it adds "-b" to set opt_get_fragments to false and
suppress byte runs from being printed:

  https://github.com/jonstewart/sleuthkit/commit/bcdc5f7b1c1123c73009eea2b6cc6c6746e3bdc1


However, both -g and -b only make if "opt_md5 || opt_sha1 || opt_save
|| do_plugin || opt_magic" is false.

My questions are:

 1. Does this change (setting opt_get_fragments to true by default,
adding -b to disable it) make sense to folks?

 2. Does it make sense to add a check so that if (opt_md5 || opt_sha1
|| opt_save || do_plugin || opt_magic) is true, then "-g" is
overridden and the content is always retrieved?


cheers,


Jon
-- 
Jon Stewart, Principal
(646) 719-0317 | jo...@li... | Arlington, VA

[sleuthkit-developers] [ sleuthkit-Bugs-3596212 ] configure.ac looks for wrong libewf function

[SourceForge.net <no...@so...>]

Bugs item #3596212, was opened at 2012-12-14 21:26
Message generated for change (Settings changed) made by carrier
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=477889&aid=3596212&group_id=55685

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Other
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Private: No
Submitted By: Joachim Metz (jbmetz)
Assigned to: Nobody/Anonymous (nobody)
Summary: configure.ac looks for wrong libewf function

Initial Comment:
in configure.ac please change libewf_open to libewf_get_version.

libewf_open is v1 API, libewf_handle_open is v2, libewf_get_version should be in both.


----------------------------------------------------------------------

>Comment By: Brian Carrier (carrier)
Date: 2013-01-28 13:43

Message:
Fixed in master:

[master ee55152] Fixed detection of libewf v2 API


----------------------------------------------------------------------

Comment By: Joachim Metz (jbmetz)
Date: 2013-01-28 06:21

Message:
If you solely want to detect the presence of libewf on the system, then yes
checking for libewf_get_version() works for both the v1 and v2 API.

----------------------------------------------------------------------

Comment By: Brian Carrier (carrier)
Date: 2013-01-28 06:15

Message:
So you suggest we should check for libewf_get_version instead?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=477889&aid=3596212&group_id=55685

[sleuthkit-developers] [ sleuthkit-Bugs-3596212 ] configure.ac looks for wrong libewf function

[SourceForge.net <no...@so...>]

Bugs item #3596212, was opened at 2012-12-14 21:26
Message generated for change (Comment added) made by jbmetz
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=477889&aid=3596212&group_id=55685

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Other
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Joachim Metz (jbmetz)
Assigned to: Nobody/Anonymous (nobody)
Summary: configure.ac looks for wrong libewf function

Initial Comment:
in configure.ac please change libewf_open to libewf_get_version.

libewf_open is v1 API, libewf_handle_open is v2, libewf_get_version should be in both.


----------------------------------------------------------------------

>Comment By: Joachim Metz (jbmetz)
Date: 2013-01-28 06:21

Message:
If you solely want to detect the presence of libewf on the system, then yes
checking for libewf_get_version() works for both the v1 and v2 API.

----------------------------------------------------------------------

Comment By: Brian Carrier (carrier)
Date: 2013-01-28 06:15

Message:
So you suggest we should check for libewf_get_version instead?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=477889&aid=3596212&group_id=55685

[sleuthkit-developers] [ sleuthkit-Bugs-3596212 ] configure.ac looks for wrong libewf function

[SourceForge.net <no...@so...>]

Bugs item #3596212, was opened at 2012-12-14 21:26
Message generated for change (Comment added) made by carrier
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=477889&aid=3596212&group_id=55685

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Other
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Joachim Metz (jbmetz)
Assigned to: Nobody/Anonymous (nobody)
Summary: configure.ac looks for wrong libewf function

Initial Comment:
in configure.ac please change libewf_open to libewf_get_version.

libewf_open is v1 API, libewf_handle_open is v2, libewf_get_version should be in both.


----------------------------------------------------------------------

>Comment By: Brian Carrier (carrier)
Date: 2013-01-28 06:15

Message:
So you suggest we should check for libewf_get_version instead?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=477889&aid=3596212&group_id=55685

Re: [sleuthkit-developers] Partecipate to translation

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

Hi Luca,

The basics can be found here:

    http://bits.netbeans.org/dev/javadoc/org-openide-modules/org/openide/modules/doc-files/i18n-branding.html

That being said, we know the following:
- There are strings in the bundles.properties files that are no longer in the UI. We need to clean those files up so that only the needed strings are translated.
- Not all strings made their way into that file.  So, we need to externalize some of them. 

brian


On Jan 23, 2013, at 1:34 PM, LUCA CALCATERRA <cal...@gm...> wrote:

> Hi, it's possible to translate Autopsy in another Language ? I can do it in Italian (if is possible even)
> 
> Luca
> ------------------------------------------------------------------------------
> Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS,
> MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current
> with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft
> MVPs and experts. ON SALE this month only -- learn more at:
> http://p.sf.net/sfu/learnnow-d2d_______________________________________________
> sleuthkit-developers mailing list
> sle...@li...
> https://lists.sourceforge.net/lists/listinfo/sleuthkit-developers

[sleuthkit-developers] Autopsy 3.0.4 compiled.. index doesn't works

[Adam M. <ama...@ba...>]

Solutions:

1) development build requires java executable (from JRE or JDK) be in the
system PATH for the indexing engine to work.  Please check if it's the case
2) alternatively, run the official 3.0.4 build.

Could be some other issue too (such as various antivirus/security software
blocking autopsy -> indexer communication).

Adam

[sleuthkit-developers] Partecipate to translation

[LUCA C. <cal...@gm...>]

Hi, it's possible to translate Autopsy in another Language ? I can do it in
Italian (if is possible even)

Luca

[sleuthkit-developers] Autopsy 3.0.4 compiled.. index doesn't works

[LUCA C. <cal...@gm...>]

I've compiled the 3.0.4 version on Windows and all it's ok...

But after adding and image index doesn't work and searching for keywords
say me no index file was created.

What's to do ?

Thnx

Re: [sleuthkit-developers] Index files to text file or database

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

Not in the tool itself, but it's a Lucene/SOLR index behind the scenes.  So, some googling may reveal ways of doing it.


On Jan 10, 2013, at 4:12 AM, Omnium Infinity <om...@ou...> wrote:

> Hi,
> 
> Is there a way to extract the indexed words in Autospy (windows version) to a text file? Or read each extracted word and insert into a database?
> 
> Basically I am trying to create a Soundex engine based on all the indexed words so trying to create a database base with all the keywords and their equivalent Soundex Code.
> 
> Thanks!
> 
> Hassan
> ------------------------------------------------------------------------------
> Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS,
> MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current
> with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft
> MVPs and experts. ON SALE this month only -- learn more at:
> http://p.sf.net/sfu/learnmore_122712_______________________________________________
> sleuthkit-developers mailing list
> sle...@li...
> https://lists.sourceforge.net/lists/listinfo/sleuthkit-developers

[sleuthkit-developers] Index files to text file or database

[Omnium I. <om...@ou...>]

Hi,
Is there a way to extract the indexed words in Autospy (windows version) to a text file? Or read each extracted word and insert into a database?
Basically I am trying to create a Soundex engine based on all the indexed words so trying to create a database base with all the keywords and their equivalent Soundex Code.
Thanks!
Hassan