sleuthkit-developers Mailing List for The Sleuth Kit (Page 20)
Brought to you by:
carrier
Menu
▾
▴
sleuthkit-developers — A list to discuss development of new features of The Sleuth Kit and Autopsy
You can subscribe to this list here.
| 2003 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(10) |
Sep
(2) |
Oct
|
Nov
(1) |
Dec
|
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2004 |
Jan
(22) |
Feb
(39) |
Mar
(8) |
Apr
(17) |
May
(10) |
Jun
(2) |
Jul
(6) |
Aug
(4) |
Sep
(1) |
Oct
(3) |
Nov
|
Dec
|
| 2005 |
Jan
(2) |
Feb
(6) |
Mar
(2) |
Apr
(2) |
May
(13) |
Jun
(2) |
Jul
|
Aug
|
Sep
(5) |
Oct
|
Nov
(2) |
Dec
|
| 2006 |
Jan
|
Feb
|
Mar
(1) |
Apr
|
May
(2) |
Jun
(9) |
Jul
(4) |
Aug
(2) |
Sep
|
Oct
(1) |
Nov
(9) |
Dec
(4) |
| 2007 |
Jan
(1) |
Feb
(2) |
Mar
|
Apr
(3) |
May
|
Jun
|
Jul
(6) |
Aug
|
Sep
(4) |
Oct
|
Nov
|
Dec
(2) |
| 2008 |
Jan
(4) |
Feb
|
Mar
|
Apr
(1) |
May
|
Jun
(9) |
Jul
(14) |
Aug
|
Sep
(5) |
Oct
(10) |
Nov
(4) |
Dec
(7) |
| 2009 |
Jan
(7) |
Feb
(10) |
Mar
(10) |
Apr
(19) |
May
(16) |
Jun
(3) |
Jul
(9) |
Aug
(5) |
Sep
(5) |
Oct
(16) |
Nov
(35) |
Dec
(30) |
| 2010 |
Jan
(4) |
Feb
(24) |
Mar
(25) |
Apr
(31) |
May
(11) |
Jun
(9) |
Jul
(11) |
Aug
(31) |
Sep
(11) |
Oct
(10) |
Nov
(15) |
Dec
(3) |
| 2011 |
Jan
(8) |
Feb
(17) |
Mar
(14) |
Apr
(2) |
May
(4) |
Jun
(4) |
Jul
(3) |
Aug
(7) |
Sep
(18) |
Oct
(8) |
Nov
(16) |
Dec
(1) |
| 2012 |
Jan
(9) |
Feb
(2) |
Mar
(3) |
Apr
(13) |
May
(10) |
Jun
(7) |
Jul
(1) |
Aug
(5) |
Sep
|
Oct
(3) |
Nov
(19) |
Dec
(3) |
| 2013 |
Jan
(16) |
Feb
(3) |
Mar
(2) |
Apr
(4) |
May
|
Jun
(3) |
Jul
(2) |
Aug
(17) |
Sep
(6) |
Oct
(1) |
Nov
|
Dec
(4) |
| 2014 |
Jan
(2) |
Feb
|
Mar
(3) |
Apr
(7) |
May
(6) |
Jun
(1) |
Jul
(18) |
Aug
|
Sep
(3) |
Oct
(1) |
Nov
(26) |
Dec
(7) |
| 2015 |
Jan
(5) |
Feb
(1) |
Mar
(2) |
Apr
|
May
(1) |
Jun
(1) |
Jul
(5) |
Aug
(7) |
Sep
(4) |
Oct
(1) |
Nov
(1) |
Dec
|
| 2016 |
Jan
(3) |
Feb
|
Mar
(1) |
Apr
|
May
(1) |
Jun
(13) |
Jul
(23) |
Aug
(2) |
Sep
(11) |
Oct
|
Nov
(1) |
Dec
|
| 2017 |
Jan
(4) |
Feb
|
Mar
|
Apr
(2) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(2) |
Dec
|
| 2018 |
Jan
|
Feb
|
Mar
(2) |
Apr
|
May
(1) |
Jun
(3) |
Jul
|
Aug
|
Sep
(2) |
Oct
|
Nov
(2) |
Dec
|
| 2019 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(2) |
Sep
|
Oct
|
Nov
|
Dec
|
| 2020 |
Jan
(4) |
Feb
|
Mar
|
Apr
|
May
|
Jun
(3) |
Jul
(5) |
Aug
(1) |
Sep
|
Oct
|
Nov
|
Dec
|
| 2021 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(1) |
Dec
|
| 2024 |
Jan
|
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(1) |
|
From: SourceForge.net <no...@so...> - 2010-08-23 15:41:11
|
Feature Requests item #3051615, was opened at 2010-08-23 10:41 Message generated for change (Tracker Item Submitted) made by carrier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477892&aid=3051615&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: Brian Carrier (carrier) Assigned to: Nobody/Anonymous (nobody) Summary: Add Volume Slack virtual file Initial Comment: Add a virtual file for each file system to account for the sectors in a volume that are not being used by the file system. Things to consider: - Should these be block or sector sized? - The FS_OPEN routine currently doesn\'t know anything about when the volume officially ends. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477892&aid=3051615&group_id=55685 |
|
From: SourceForge.net <no...@so...> - 2010-08-23 13:19:16
|
Bugs item #3051400, was opened at 2010-08-23 05:19 Message generated for change (Comment added) made by carrier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=3051400&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: Open Resolution: None Priority: 5 Private: No Submitted By: Rob J Meijer (ghede) Assigned to: Nobody/Anonymous (nobody) Summary: Invalid UTF8 sequences as file/dir names. Initial Comment: When processing the hda5 image from the honeynet test images ( http://old.honeynet.org/misc/files/challenge-images.tar ) the directory with inode 32169 when invoked with tsk_fs_dir_open_meta, produces multiple names that contain invalid UTF8 sequences. ---------------------------------------------------------------------- >Comment By: Brian Carrier (carrier) Date: 2010-08-23 08:19 Message: Meaning that they are invalid in the image and TSK simply shows you the invalid sequences or that they are valid in the image and TSK makes them invalid. Is this in 3.1 or the trunk? Thanks. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=3051400&group_id=55685 |
|
From: SourceForge.net <no...@so...> - 2010-08-23 10:19:45
|
Bugs item #3051400, was opened at 2010-08-23 12:19 Message generated for change (Tracker Item Submitted) made by ghede You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=3051400&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: Open Resolution: None Priority: 5 Private: No Submitted By: Rob J Meijer (ghede) Assigned to: Nobody/Anonymous (nobody) Summary: Invalid UTF8 sequences as file/dir names. Initial Comment: When processing the hda5 image from the honeynet test images ( http://old.honeynet.org/misc/files/challenge-images.tar ) the directory with inode 32169 when invoked with tsk_fs_dir_open_meta, produces multiple names that contain invalid UTF8 sequences. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=3051400&group_id=55685 |
|
From: SourceForge.net <no...@so...> - 2010-08-19 20:26:54
|
Bugs item #3026994, was opened at 2010-07-08 14:28 Message generated for change (Settings changed) made by carrier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=3026994&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 Resolution: None Priority: 5 Private: No Submitted By: Brian Carrier (carrier) >Assigned to: Brian Carrier (carrier) Summary: mingw compile errors Initial Comment: >From Simson Garfinkel: Version 3.1.3 generates these compilation errors with mingw running on Linux: fs_fname_apis.cpp: In function `int test_fat12()': fs_fname_apis.cpp:366: error: cannot convert `char*' to `const TSK_TCHAR*' for argument `1' to `TSK_IMG_INFO* tsk_img_open_sing(const TSK_TCHAR*, TSK_IMG_TYPE_ENUM, unsigned int)' fs_fname_apis.cpp: In function `int test_ntfs_fe()': fs_fname_apis.cpp:404: error: cannot convert `char*' to `const TSK_TCHAR*' for argument `1' to `TSK_IMG_INFO* tsk_img_open_sing(const TSK_TCHAR*, TSK_IMG_TYPE_ENUM, unsigned int)' read_apis.cpp: In function `int test_fat12()': read_apis.cpp:210: error: cannot convert `char*' to `const TSK_TCHAR*' for argument `1' to `TSK_IMG_INFO* tsk_img_open_sing(const TSK_TCHAR*, TSK_IMG_TYPE_ENUM, unsigned int)'fs_attrlist_apis.cpp: In function `int test_fat12()': fs_attrlist_apis.cpp:202: error: cannot convert `char*' to `const TSK_TCHAR*' for argument `1' to `TSK_IMG_INFO* tsk_img_open_sing(const TSK_TCHAR*, TSK_IMG_TYPE_ENUM, unsigned int)' read_apis.cpp: In function `int test_fat_slack()': read_apis.cpp:249: error: cannot convert `char*' to `const TSK_TCHAR*' for argument `1' to `TSK_IMG_INFO* tsk_img_open_sing(const TSK_TCHAR*, TSK_IMG_TYPE_ENUM, unsigned int)' fs_attrlist_apis.cpp: In function `int test_ntfs_fe()': fs_attrlist_apis.cpp:241: error: cannot convert `char*' to `const TSK_TCHAR*' for argument `1' to `TSK_IMG_INFO* tsk_img_open_sing(const TSK_TCHAR*, TSK_IMG_TYPE_ENUM, unsigned int)' read_apis.cpp: In function `int test_fat_recover()': read_apis.cpp:343: error: cannot convert `char*' to `const TSK_TCHAR*' for argument `1' to `TSK_IMG_INFO* tsk_img_open_sing(const TSK_TCHAR*, TSK_IMG_TYPE_ENUM, unsigned int)' read_apis.cpp: In function `int test_ntfs_slack_ads()': read_apis.cpp:483: error: cannot convert `char*' to `const TSK_TCHAR*' for argument `1' to `TSK_IMG_INFO* tsk_img_open_sing(const TSK_TCHAR*, TSK_IMG_TYPE_ENUM, unsigned int)' read_apis.cpp: In function `int test_ntfs_fe()': read_apis.cpp:644: error: cannot convert `char*' to `const TSK_TCHAR*' for argument `1' to `TSK_IMG_INFO* tsk_img_open_sing(const TSK_TCHAR*, TSK_IMG_TYPE_ENUM, unsigned int)' read_apis.cpp: In function `int test_ntfs_comp()': read_apis.cpp:682: error: cannot convert `char*' to `const TSK_TCHAR*' for argument `1' to `TSK_IMG_INFO* tsk_img_open_sing(const TSK_TCHAR*, TSK_IMG_TYPE_ENUM, unsigned int)' These are all trivially fixed by putting a (const TSK_TCHAR *) before the fname arguments. I am also seeing these errors which are not so trivial to fix: ewf.c: In function `ewf_open': ewf.c:147: warning: implicit declaration of function `libewf_check_file_signature_wide' ewf.c:163: warning: implicit declaration of function `libewf_open_wide' ewf.c:163: warning: assignment makes pointer from integer without a cast hfs_dent.c: In function `hfs_uni2ascii': hfs_dent.c:121: warning: dereferencing type-punned pointer will break strict-aliasing rules hfs_dent.c:122: warning: dereferencing type-punned pointer will break strict-aliasing rules ---------------------------------------------------------------------- Comment By: Brian Carrier (carrier) Date: 2010-08-19 15:26 Message: First part of patch is in: Sending trunk/tests/fs_attrlist_apis.cpp Sending trunk/tests/fs_fname_apis.cpp Sending trunk/tests/read_apis.cpp Transmitting file data ... Committed revision 238. Need to look at ewf_open warning. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=3026994&group_id=55685 |
|
From: SourceForge.net <no...@so...> - 2010-08-19 20:26:43
|
Bugs item #3026994, was opened at 2010-07-08 14:28 Message generated for change (Comment added) made by carrier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=3026994&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 Resolution: None Priority: 5 Private: No Submitted By: Brian Carrier (carrier) Assigned to: anthony lawrence (anthonylawrence) Summary: mingw compile errors Initial Comment: >From Simson Garfinkel: Version 3.1.3 generates these compilation errors with mingw running on Linux: fs_fname_apis.cpp: In function `int test_fat12()': fs_fname_apis.cpp:366: error: cannot convert `char*' to `const TSK_TCHAR*' for argument `1' to `TSK_IMG_INFO* tsk_img_open_sing(const TSK_TCHAR*, TSK_IMG_TYPE_ENUM, unsigned int)' fs_fname_apis.cpp: In function `int test_ntfs_fe()': fs_fname_apis.cpp:404: error: cannot convert `char*' to `const TSK_TCHAR*' for argument `1' to `TSK_IMG_INFO* tsk_img_open_sing(const TSK_TCHAR*, TSK_IMG_TYPE_ENUM, unsigned int)' read_apis.cpp: In function `int test_fat12()': read_apis.cpp:210: error: cannot convert `char*' to `const TSK_TCHAR*' for argument `1' to `TSK_IMG_INFO* tsk_img_open_sing(const TSK_TCHAR*, TSK_IMG_TYPE_ENUM, unsigned int)'fs_attrlist_apis.cpp: In function `int test_fat12()': fs_attrlist_apis.cpp:202: error: cannot convert `char*' to `const TSK_TCHAR*' for argument `1' to `TSK_IMG_INFO* tsk_img_open_sing(const TSK_TCHAR*, TSK_IMG_TYPE_ENUM, unsigned int)' read_apis.cpp: In function `int test_fat_slack()': read_apis.cpp:249: error: cannot convert `char*' to `const TSK_TCHAR*' for argument `1' to `TSK_IMG_INFO* tsk_img_open_sing(const TSK_TCHAR*, TSK_IMG_TYPE_ENUM, unsigned int)' fs_attrlist_apis.cpp: In function `int test_ntfs_fe()': fs_attrlist_apis.cpp:241: error: cannot convert `char*' to `const TSK_TCHAR*' for argument `1' to `TSK_IMG_INFO* tsk_img_open_sing(const TSK_TCHAR*, TSK_IMG_TYPE_ENUM, unsigned int)' read_apis.cpp: In function `int test_fat_recover()': read_apis.cpp:343: error: cannot convert `char*' to `const TSK_TCHAR*' for argument `1' to `TSK_IMG_INFO* tsk_img_open_sing(const TSK_TCHAR*, TSK_IMG_TYPE_ENUM, unsigned int)' read_apis.cpp: In function `int test_ntfs_slack_ads()': read_apis.cpp:483: error: cannot convert `char*' to `const TSK_TCHAR*' for argument `1' to `TSK_IMG_INFO* tsk_img_open_sing(const TSK_TCHAR*, TSK_IMG_TYPE_ENUM, unsigned int)' read_apis.cpp: In function `int test_ntfs_fe()': read_apis.cpp:644: error: cannot convert `char*' to `const TSK_TCHAR*' for argument `1' to `TSK_IMG_INFO* tsk_img_open_sing(const TSK_TCHAR*, TSK_IMG_TYPE_ENUM, unsigned int)' read_apis.cpp: In function `int test_ntfs_comp()': read_apis.cpp:682: error: cannot convert `char*' to `const TSK_TCHAR*' for argument `1' to `TSK_IMG_INFO* tsk_img_open_sing(const TSK_TCHAR*, TSK_IMG_TYPE_ENUM, unsigned int)' These are all trivially fixed by putting a (const TSK_TCHAR *) before the fname arguments. I am also seeing these errors which are not so trivial to fix: ewf.c: In function `ewf_open': ewf.c:147: warning: implicit declaration of function `libewf_check_file_signature_wide' ewf.c:163: warning: implicit declaration of function `libewf_open_wide' ewf.c:163: warning: assignment makes pointer from integer without a cast hfs_dent.c: In function `hfs_uni2ascii': hfs_dent.c:121: warning: dereferencing type-punned pointer will break strict-aliasing rules hfs_dent.c:122: warning: dereferencing type-punned pointer will break strict-aliasing rules ---------------------------------------------------------------------- >Comment By: Brian Carrier (carrier) Date: 2010-08-19 15:26 Message: First part of patch is in: Sending trunk/tests/fs_attrlist_apis.cpp Sending trunk/tests/fs_fname_apis.cpp Sending trunk/tests/read_apis.cpp Transmitting file data ... Committed revision 238. Need to look at ewf_open warning. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=3026994&group_id=55685 |
|
From: SourceForge.net <no...@so...> - 2010-08-19 20:23:46
|
Bugs item #2993806, was opened at 2010-04-28 15:26 Message generated for change (Comment added) made by carrier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=2993806&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: anthony lawrence (anthonylawrence) Summary: Add enum value for no flags Initial Comment: Some of the enums don't have a setting for no flags (such as TSK_FS_FILE_READ_FLAG_ENUM). Add a setting that represents no flags. ---------------------------------------------------------------------- >Comment By: Brian Carrier (carrier) Date: 2010-08-19 15:23 Message: Anthony fixed this. Sending trunk/NEWS.txt Sending trunk/tsk3/fs/ntfs.c Sending trunk/tsk3/fs/tsk_fs.h Transmitting file data ... Committed revision 237. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=2993806&group_id=55685 |
|
From: SourceForge.net <no...@so...> - 2010-08-18 15:31:52
|
Bugs item #3043810, was opened at 2010-08-12 12:38 Message generated for change (Comment added) made by ekelak You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=3043810&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: Image File Tools Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Janet (ekelak) Assigned to: anthony lawrence (anthonylawrence) Summary: 2gb split image file limit Initial Comment: Can not read an split image where each file is of size 2gb. Found that TSTAT (defined in tsk_os.h) was returning a negative file size with no error when used in split.c. Possible Fix: Change TSTAT to _wstat64 and STAT_STR to stat64. ---------------------------------------------------------------------- >Comment By: Janet (ekelak) Date: 2010-08-18 11:31 Message: I couldn't read the split image on Windows XP Pro 64 and 32-bit ---------------------------------------------------------------------- Comment By: Brian Carrier (carrier) Date: 2010-08-17 17:51 Message: What OS was this on? Most of the OSes now map to the 64-bit version. ---------------------------------------------------------------------- Comment By: Brian Carrier (carrier) Date: 2010-08-13 12:24 Message: We need to investigate what other methods use TSTAT to see if a new TSTAT64 should be created or if we should just change the mapping. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=3043810&group_id=55685 |
|
From: SourceForge.net <no...@so...> - 2010-08-17 21:51:07
|
Bugs item #3043810, was opened at 2010-08-12 11:38 Message generated for change (Comment added) made by carrier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=3043810&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: Image File Tools Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Janet (ekelak) Assigned to: anthony lawrence (anthonylawrence) Summary: 2gb split image file limit Initial Comment: Can not read an split image where each file is of size 2gb. Found that TSTAT (defined in tsk_os.h) was returning a negative file size with no error when used in split.c. Possible Fix: Change TSTAT to _wstat64 and STAT_STR to stat64. ---------------------------------------------------------------------- >Comment By: Brian Carrier (carrier) Date: 2010-08-17 16:51 Message: What OS was this on? Most of the OSes now map to the 64-bit version. ---------------------------------------------------------------------- Comment By: Brian Carrier (carrier) Date: 2010-08-13 11:24 Message: We need to investigate what other methods use TSTAT to see if a new TSTAT64 should be created or if we should just change the mapping. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=3043810&group_id=55685 |
|
From: SourceForge.net <no...@so...> - 2010-08-17 21:47:58
|
Bugs item #3043092, was opened at 2010-08-11 09:15 Message generated for change (Comment added) made by carrier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=3043092&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: Brian Carrier (carrier) Summary: ifind fs-specific logic has issues Initial Comment: The code in ifind-lib has some minor logic issues. It defaults to the Unix file systems if it is not FAT or NTFS and the Unix-specific flags of no-sparse are no longer needed. ---------------------------------------------------------------------- >Comment By: Brian Carrier (carrier) Date: 2010-08-17 16:47 Message: Verified on regression tests. ---------------------------------------------------------------------- Comment By: Brian Carrier (carrier) Date: 2010-08-11 09:43 Message: Fixed in trunk. Need to run regression tests to verify on more file systems. Sending trunk/NEWS.txt Sending trunk/tools/fstools/ifind.cpp Sending trunk/tsk3/fs/ifind_lib.c Transmitting file data ... Committed revision 230. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=3043092&group_id=55685 |
|
From: SourceForge.net <no...@so...> - 2010-08-13 16:29:43
|
Feature Requests item #3017764, was opened at 2010-06-17 16:13 Message generated for change (Settings changed) made by carrier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477892&aid=3017764&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: https://www.google.com/accounts () >Assigned to: Brian Carrier (carrier) Summary: Naming the default $DATA as "$Data" Initial Comment: Currently, TSK assigns the name "$Data" to a file's default $DATA attribute. However, this makes it difficult to distinguish the file's default $DATA attribute from an ADS named "$Data". For exaple, you can actually name a stream "$Data" like this: C:\> echo 1 > host.txt:$Data Now when you use fls, it shows something like this: ++++ r/r 201337-128-1: host.txt ++++ r/r 201337-128-3: host.txt A lot of people rely on grepping fls output for ":" to identify streams, but if the stream is actually named "$Data" then fls won't show it as such. One thing you could do is apply the "$Data" name inside the tsk_fs_name_print function if a $DATA attribute doesn't have a name. That way, the structure member fs_attr->name contains the original name (which would just be "" in the default case) so that applications can tell it apart from an ADS named "$Data". Thanks. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477892&aid=3017764&group_id=55685 |
|
From: SourceForge.net <no...@so...> - 2010-08-13 16:27:53
|
Feature Requests item #3026989, was opened at 2010-07-08 14:18 Message generated for change (Settings changed) made by carrier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477892&aid=3026989&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: Image Layer Group: None Status: Open Priority: 5 Private: No Submitted By: Brian Carrier (carrier) >Assigned to: Brian Carrier (carrier) Summary: specify range in img_cat (patch included) Initial Comment: Simson submitted a patch to specify range in img_cat. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477892&aid=3026989&group_id=55685 |
|
From: SourceForge.net <no...@so...> - 2010-08-13 16:25:57
|
Feature Requests item #2941805, was opened at 2010-01-28 15:15 Message generated for change (Settings changed) made by carrier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477892&aid=2941805&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: Rob (robjoyce) >Assigned to: Brian Carrier (carrier) Summary: Show case sensitive flag in HFSX fsstat Initial Comment: The attached patch prints the case-sensitivity flag in fsstat when analyzing an HFSX volume. (It also removes an errant space in File System Version.) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477892&aid=2941805&group_id=55685 |
|
From: SourceForge.net <no...@so...> - 2010-08-13 16:24:34
|
Bugs item #3043810, was opened at 2010-08-12 11:38 Message generated for change (Comment added) made by carrier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=3043810&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: Image File Tools Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Janet (ekelak) >Assigned to: anthony lawrence (anthonylawrence) Summary: 2gb split image file limit Initial Comment: Can not read an split image where each file is of size 2gb. Found that TSTAT (defined in tsk_os.h) was returning a negative file size with no error when used in split.c. Possible Fix: Change TSTAT to _wstat64 and STAT_STR to stat64. ---------------------------------------------------------------------- >Comment By: Brian Carrier (carrier) Date: 2010-08-13 11:24 Message: We need to investigate what other methods use TSTAT to see if a new TSTAT64 should be created or if we should just change the mapping. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=3043810&group_id=55685 |
|
From: SourceForge.net <no...@so...> - 2010-08-13 16:21:43
|
Bugs item #3031168, was opened at 2010-07-18 04:27 Message generated for change (Comment added) made by carrier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=3031168&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: Invalid Priority: 5 Private: No Submitted By: Negin Ahmadian (negin99) Assigned to: Nobody/Anonymous (nobody) Summary: Problem with Ext3 recovered files and directories Initial Comment: Hi! I tried TSK with a test image of 4.9MB Ext3 file system. This image has five deleted files and two directories (see attached excel file for files' description). The files rang from single block files to multiple blocks. No data structures were also modified. They were created in Fedora 8.0, deleted in Fedora 8.0 and imaged in Fedora 8.0. After deletion, size of all the deleted files becomes 0 and they will not be accessible. (CR01-1 picture shows what happens, there is no link available for dir1!) I tried FAT images and it seems that they work fine. All of the deleted files could be recovered after deletion. ---------------------------------------------------------------------- >Comment By: Brian Carrier (carrier) Date: 2010-08-13 11:21 Message: Different files systems have different ways of deleting files. With Ext3, the pointers to the file content and the file size are wiped. With FAT, many of the pointers are wiped, but the first pointer isn't and the size isn't. So, recovery is sometimes possible with FAT, but it isn't with Ext3 if you want to rely only on file system data. Ext3 requires either using the journal or file carving techniques. TSK doesn't use these recovery techniques. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=3031168&group_id=55685 |
|
From: SourceForge.net <no...@so...> - 2010-08-13 16:18:53
|
Bugs item #3026994, was opened at 2010-07-08 14:28 Message generated for change (Settings changed) made by carrier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=3026994&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 Resolution: None Priority: 5 Private: No Submitted By: Brian Carrier (carrier) >Assigned to: anthony lawrence (anthonylawrence) Summary: mingw compile errors Initial Comment: >From Simson Garfinkel: Version 3.1.3 generates these compilation errors with mingw running on Linux: fs_fname_apis.cpp: In function `int test_fat12()': fs_fname_apis.cpp:366: error: cannot convert `char*' to `const TSK_TCHAR*' for argument `1' to `TSK_IMG_INFO* tsk_img_open_sing(const TSK_TCHAR*, TSK_IMG_TYPE_ENUM, unsigned int)' fs_fname_apis.cpp: In function `int test_ntfs_fe()': fs_fname_apis.cpp:404: error: cannot convert `char*' to `const TSK_TCHAR*' for argument `1' to `TSK_IMG_INFO* tsk_img_open_sing(const TSK_TCHAR*, TSK_IMG_TYPE_ENUM, unsigned int)' read_apis.cpp: In function `int test_fat12()': read_apis.cpp:210: error: cannot convert `char*' to `const TSK_TCHAR*' for argument `1' to `TSK_IMG_INFO* tsk_img_open_sing(const TSK_TCHAR*, TSK_IMG_TYPE_ENUM, unsigned int)'fs_attrlist_apis.cpp: In function `int test_fat12()': fs_attrlist_apis.cpp:202: error: cannot convert `char*' to `const TSK_TCHAR*' for argument `1' to `TSK_IMG_INFO* tsk_img_open_sing(const TSK_TCHAR*, TSK_IMG_TYPE_ENUM, unsigned int)' read_apis.cpp: In function `int test_fat_slack()': read_apis.cpp:249: error: cannot convert `char*' to `const TSK_TCHAR*' for argument `1' to `TSK_IMG_INFO* tsk_img_open_sing(const TSK_TCHAR*, TSK_IMG_TYPE_ENUM, unsigned int)' fs_attrlist_apis.cpp: In function `int test_ntfs_fe()': fs_attrlist_apis.cpp:241: error: cannot convert `char*' to `const TSK_TCHAR*' for argument `1' to `TSK_IMG_INFO* tsk_img_open_sing(const TSK_TCHAR*, TSK_IMG_TYPE_ENUM, unsigned int)' read_apis.cpp: In function `int test_fat_recover()': read_apis.cpp:343: error: cannot convert `char*' to `const TSK_TCHAR*' for argument `1' to `TSK_IMG_INFO* tsk_img_open_sing(const TSK_TCHAR*, TSK_IMG_TYPE_ENUM, unsigned int)' read_apis.cpp: In function `int test_ntfs_slack_ads()': read_apis.cpp:483: error: cannot convert `char*' to `const TSK_TCHAR*' for argument `1' to `TSK_IMG_INFO* tsk_img_open_sing(const TSK_TCHAR*, TSK_IMG_TYPE_ENUM, unsigned int)' read_apis.cpp: In function `int test_ntfs_fe()': read_apis.cpp:644: error: cannot convert `char*' to `const TSK_TCHAR*' for argument `1' to `TSK_IMG_INFO* tsk_img_open_sing(const TSK_TCHAR*, TSK_IMG_TYPE_ENUM, unsigned int)' read_apis.cpp: In function `int test_ntfs_comp()': read_apis.cpp:682: error: cannot convert `char*' to `const TSK_TCHAR*' for argument `1' to `TSK_IMG_INFO* tsk_img_open_sing(const TSK_TCHAR*, TSK_IMG_TYPE_ENUM, unsigned int)' These are all trivially fixed by putting a (const TSK_TCHAR *) before the fname arguments. I am also seeing these errors which are not so trivial to fix: ewf.c: In function `ewf_open': ewf.c:147: warning: implicit declaration of function `libewf_check_file_signature_wide' ewf.c:163: warning: implicit declaration of function `libewf_open_wide' ewf.c:163: warning: assignment makes pointer from integer without a cast hfs_dent.c: In function `hfs_uni2ascii': hfs_dent.c:121: warning: dereferencing type-punned pointer will break strict-aliasing rules hfs_dent.c:122: warning: dereferencing type-punned pointer will break strict-aliasing rules ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=3026994&group_id=55685 |
|
From: SourceForge.net <no...@so...> - 2010-08-13 16:18:12
|
Bugs item #3023481, was opened at 2010-06-30 13:35 Message generated for change (Comment added) made by carrier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=3023481&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: Open Resolution: None Priority: 5 Private: No Submitted By: John Lehr (jlehr) Assigned to: Nobody/Anonymous (nobody) Summary: icat exporting error, FAT Initial Comment: icat of any deleted file in a FAT16 partition only export 4kb of file. The Sleuth Kit ver 3.1.3b1 Ubuntu 10.04 ---------------------------------------------------------------------- >Comment By: Brian Carrier (carrier) Date: 2010-08-13 11:18 Message: If you still have the image, can you run 'istat' on the files that are not recovering as much as you expect (and not 'fsstat' on the full file system). Because of the way that FAT deletes files, TSK can't always figure out where the file used to be. It tries to guess where it was, but if it can't figure it out then it will only recover the first cluster of the file (which is stored in the directory entry). ---------------------------------------------------------------------- Comment By: Brian Carrier (carrier) Date: 2010-06-30 21:00 Message: Can you run 'istat' on the file? It will tell you if the file is recoverable or not. ---------------------------------------------------------------------- Comment By: John Lehr (jlehr) Date: 2010-06-30 17:52 Message: more information: in a fat32 file system with 32kb clusters, icat recovered 32kb of the deleted file. Thus, the bug appears to be that icat extracts only one cluster of deleted files from fat32. ---------------------------------------------------------------------- Comment By: John Lehr (jlehr) Date: 2010-06-30 16:05 Message: Correction, Fat32 Partition: FILE SYSTEM INFORMATION -------------------------------------------- File System Type: FAT32 OEM Name: MSDOS5.0 Volume ID: 0x861f3d71 Volume Label (Boot Sector): NO NAME Volume Label (Root Directory): CRUZER File System Type Label: FAT32 Next Free Sector (FS Info): 90352 Free Sector Count (FS Info): 5609032 Sectors before file system: 63 File System Layout (in sectors) Total Range: 0 - 15695441 * Reserved: 0 - 35 ** Boot Sector: 0 ** FS Info Sector: 1 ** Backup Boot Sector: 6 * FAT 0: 36 - 15333 * FAT 1: 15334 - 30631 * Data Area: 30632 - 15695441 ** Cluster Area: 30632 - 15695439 *** Root Directory: 30632 - 30639 ** Non-clustered: 15695440 - 15695441 METADATA INFORMATION -------------------------------------------- Range: 2 - 250636966 Root Directory: 2 CONTENT INFORMATION -------------------------------------------- Sector Size: 512 Cluster Size: 4096 Total Cluster Range: 2 - 1958102 Further study shows that regular files are extracted correctly with icat and the issue is limited to deleted files over 4.0 K. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=3023481&group_id=55685 |
|
From: SourceForge.net <no...@so...> - 2010-08-13 16:15:01
|
Bugs item #2993806, was opened at 2010-04-28 15:26 Message generated for change (Settings changed) made by carrier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=2993806&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: Open Resolution: None Priority: 5 Private: No Submitted By: Brian Carrier (carrier) >Assigned to: anthony lawrence (anthonylawrence) Summary: Add enum value for no flags Initial Comment: Some of the enums don't have a setting for no flags (such as TSK_FS_FILE_READ_FLAG_ENUM). Add a setting that represents no flags. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=2993806&group_id=55685 |
|
From: SourceForge.net <no...@so...> - 2010-08-12 16:38:56
|
Bugs item #3043810, was opened at 2010-08-12 12:38 Message generated for change (Tracker Item Submitted) made by ekelak You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=3043810&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: Image File Tools Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Janet (ekelak) Assigned to: Nobody/Anonymous (nobody) Summary: 2gb split image file limit Initial Comment: Can not read an split image where each file is of size 2gb. Found that TSTAT (defined in tsk_os.h) was returning a negative file size with no error when used in split.c. Possible Fix: Change TSTAT to _wstat64 and STAT_STR to stat64. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=3043810&group_id=55685 |
|
From: SourceForge.net <no...@so...> - 2010-08-11 22:09:19
|
Feature Requests item #3012324, was opened at 2010-06-06 22:51 Message generated for change (Comment added) made by carrier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477892&aid=3012324&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: API Group: None >Status: Closed Priority: 5 Private: No Submitted By: https://www.google.com/accounts () >Assigned to: anthony lawrence (anthonylawrence) Summary: Move name mangling out of library to CLI tools Initial Comment: All of the file systems (except HFS+, but I need to add it there) have a variation of this code: for (i = 0; fs_name->name[i] != '\0'; i++) { if (TSK_IS_CNTRL(fs_name->name[i])) fs_name->name[i] = '^'; } where TSK_IS_CNTRL is defined as: #define TSK_IS_CNTRL(x) (((x) < 0x20) && ((x) >= 0x00)) This code should be moved to fls and other programs that display filenames. The API should not name mangle. ---------------------------------------------------------------------- >Comment By: Brian Carrier (carrier) Date: 2010-08-11 17:09 Message: Patch by Anthony Lawrence. Checked into trunk. Sending trunk/NEWS.txt Sending trunk/tools/autotools/tsk_recover.cpp Sending trunk/tools/autotools/tsk_recover.h Sending trunk/tsk3/fs/ext2fs_dent.c Sending trunk/tsk3/fs/fatfs_dent.c Sending trunk/tsk3/fs/ffs_dent.c Sending trunk/tsk3/fs/fs_name.c Sending trunk/tsk3/fs/iso9660_dent.c Sending trunk/tsk3/fs/ntfs_dent.c Transmitting file data ......... Committed revision 231. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477892&aid=3012324&group_id=55685 |
|
From: SourceForge.net <no...@so...> - 2010-08-11 14:43:54
|
Bugs item #3043092, was opened at 2010-08-11 09:15 Message generated for change (Comment added) made by carrier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=3043092&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: Open Resolution: None Priority: 5 Private: No Submitted By: Brian Carrier (carrier) Assigned to: Brian Carrier (carrier) Summary: ifind fs-specific logic has issues Initial Comment: The code in ifind-lib has some minor logic issues. It defaults to the Unix file systems if it is not FAT or NTFS and the Unix-specific flags of no-sparse are no longer needed. ---------------------------------------------------------------------- >Comment By: Brian Carrier (carrier) Date: 2010-08-11 09:43 Message: Fixed in trunk. Need to run regression tests to verify on more file systems. Sending trunk/NEWS.txt Sending trunk/tools/fstools/ifind.cpp Sending trunk/tsk3/fs/ifind_lib.c Transmitting file data ... Committed revision 230. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=3043092&group_id=55685 |
|
From: SourceForge.net <no...@so...> - 2010-08-11 14:15:13
|
Bugs item #3043092, was opened at 2010-08-11 09:15 Message generated for change (Tracker Item Submitted) made by carrier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=3043092&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: Open Resolution: None Priority: 5 Private: No Submitted By: Brian Carrier (carrier) Assigned to: Brian Carrier (carrier) Summary: ifind fs-specific logic has issues Initial Comment: The code in ifind-lib has some minor logic issues. It defaults to the Unix file systems if it is not FAT or NTFS and the Unix-specific flags of no-sparse are no longer needed. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=3043092&group_id=55685 |
|
From: SourceForge.net <no...@so...> - 2010-08-04 04:52:51
|
Feature Requests item #2206304, was opened at 2008-10-29 07:13 Message generated for change (Comment added) made by negin99 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477892&aid=2206304&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: API Group: None Status: Open Priority: 5 Private: No Submitted By: Brian Carrier (carrier) Assigned to: Nobody/Anonymous (nobody) Summary: ffind more library friendly Initial Comment: The ffind library code could be made more library friendly by not printing the data to stdout etc. ---------------------------------------------------------------------- Comment By: Negin Ahmadian (negin99) Date: 2010-08-04 09:22 Message: This request is done and the modified files could be found here: http://sourceforge.net/tracker/?func=detail&aid=3015367&group_id=55685&atid=477892 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477892&aid=2206304&group_id=55685 |
|
From: SourceForge.net <no...@so...> - 2010-07-28 15:50:38
|
Feature Requests item #3036083, was opened at 2010-07-28 11:50 Message generated for change (Tracker Item Submitted) made by You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477892&aid=3036083&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: API Group: None Status: Open Priority: 5 Private: No Submitted By: Jon S () Assigned to: Nobody/Anonymous (nobody) Summary: TSK_FS_NAME has unique ID field Initial Comment: Add a field to the TSK_FS_NAME struct that can be used as a unique identifier and is stable relative to small differences in file system parsing. The normal case is when a TSK_FS_NAME struct represents a filesystem record. In this case, the field will be populated with the byte offset of the record. This is useful, as it allows users the chance to refer to the structure manually, e.g., in a hex editor. For TSK_FS_NAME structs that have been generated by TSK, e.g., for orphan files, then the field will be populated with the address of the metadata record. That is, it'll have the same value as TSK_FS_NAME::meta_addr. This is also guaranteed to be unique. c.f. https://sourceforge.net/mailarchive/forum.php?thread_name=9FAC1C96-926D-4F16-B59F-16C02C157377%40sleuthkit.org&forum_name=sleuthkit-developers ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477892&aid=3036083&group_id=55685 |
|
From: Brian C. <ca...@sl...> - 2010-07-27 17:24:11
|
On Jul 21, 2010, at 11:12 PM, Jon Stewart wrote: > The primary use case is to have an identifier that uniquely identifies > a TSK_FS_NAME record, which ideally would be compact and stable-ish > (if the fs interpretation changed slightly, most records would be > unaffected). The secondary use case is to give folks a pointer to > where the relevant record may be on disk (e.g., MFT record), while > obviously making allowances for filesystem variations. > > My understanding is that a path may not be unique as a > deleted&recoverable file may have the same path as an allocated file. > There would be separate TSK_FS_NAME records but they'd have the same > paths. (Please correct me if I'm mistaken in how tsk handles this > situation.) TSK will de-duplicate files if they have the same name and metadata address. So, yes an allocated file and a deleted file could have the same name if they refer to different metadata structures. > What I'd propose is an unsigned int in the TSK_FS_NAME struct, which > would hold the byte offset of the record on disk, thereby > distinguishing it. Not sure what to put for orphan files, but those > are easy enough to determine, and we know they can be identified > uniquely via the metadata address (right?). When in doubt, MAX_INT. I suppose we could also just use the address of the metadata structure as long as it is clear to the user that this is to be treated only as a unique identifier and not as the offset to the name. Can you add this to the feature request tracker? http://sourceforge.net/tracker/?atid=477892&group_id=55685 thanks, brian |
|
From: Jon S. <jo...@li...> - 2010-07-22 04:14:30
|
The primary use case is to have an identifier that uniquely identifies a TSK_FS_NAME record, which ideally would be compact and stable-ish (if the fs interpretation changed slightly, most records would be unaffected). The secondary use case is to give folks a pointer to where the relevant record may be on disk (e.g., MFT record), while obviously making allowances for filesystem variations. My understanding is that a path may not be unique as a deleted&recoverable file may have the same path as an allocated file. There would be separate TSK_FS_NAME records but they'd have the same paths. (Please correct me if I'm mistaken in how tsk handles this situation.) What I'd propose is an unsigned int in the TSK_FS_NAME struct, which would hold the byte offset of the record on disk, thereby distinguishing it. Not sure what to put for orphan files, but those are easy enough to determine, and we know they can be identified uniquely via the metadata address (right?). When in doubt, MAX_INT. I don't need a lookup function, so no new functions or state, just adding another field to the struct. Cheers, Jon On Jul 21, 2010, at 8:35 PM, Brian Carrier <ca...@sl...> wrote: > Hi Jon, > > What is the use case for this identifier? Are you saying that a > path is not unique because you could have the same path in different > file systems in a disk image? You could use the file system offset > as part of the path to make it unique? > > That being said, sure we could make an identifier for each name. > What should it report for orphan files though (files that have a > metadata structure, but no name)? > > brian > > On Jul 21, 2010, at 1:37 PM, Jon wrote: > >> Would it be possible to add a field to TSK_FS_NAME for the byte >> offset >> of the record, either from the start of the volume or from the start >> of the disk (whichever is easier)? >> >> "addr" works as a good unique identifier for TSK_FS_META structs, and >> something similar for TSK_FS_NAME would be helpful. Paths aren't >> necessarily unique, and a segmented scheme using the parent >> directory's path/inum with the index number of the TSK_FS_NAME record >> is not stable... a new version of TSK might figure out a way to >> recover more files in a directory (hypothetically) and now the index >> number may be shifted to a different record. Reporting the byte >> offset >> of the record would be more stable and have the added benefit of >> letting people quickly find the raw data in a hex editor, for >> validation/inspection. >> >> Thoughts? >> >> Jon >> >> --- >> --- >> --- >> --------------------------------------------------------------------- >> This SF.net email is sponsored by Sprint >> What will you do first with EVO, the first 4G phone? >> Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first >> _______________________________________________ >> sleuthkit-developers mailing list >> sle...@li... >> https://lists.sourceforge.net/lists/listinfo/sleuthkit-developers > |
1 message has been excluded from this view by a project administrator.
