sleuthkit-developers Mailing List for The Sleuth Kit (Page 23)
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-04-16 13:58:27
|
Bugs item #2988330, was opened at 2010-04-16 08:58 Message generated for change (Tracker Item Submitted) made by carrier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=2988330&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: NTFS.c offset error: Initial Comment: >From Jamie Butler: Line 3128 in ntfs_proc_sii should be for (sii_buffer_offset = 0; sii_buffer_offset < sii_buffer->size; sii_buffer_offset += ntfs->idx_rsize_b) AND NOT for (sii_buffer_offset = 0; sii_buffer_offset < sii_buffer->size; sii_buffer_offset += ntfs->csize_b) { csize_b and idx_rsize_b are not necessarily the same number. This can cause a GPF. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=2988330&group_id=55685 |
|
From: BIT S. T. <bit...@gm...> - 2010-04-15 18:58:05
|
I found a bug in the command mmls -B, when you used this command the size in GB is always 0. I'd like to know how to solve this problem if it is possible. Another question is what is happening with delete HFS files, can sleuth kit retrieve or show this kind of files?. Thank you very much. |
|
From: Al M. <alp...@gm...> - 2010-04-13 19:34:22
|
Sorry it took a while. Ran it, Got something along the lines of: Side bye side configuration information for fls.exe contains errors. Apllication has failed to start... Side bye side configuration information for Libewf.dll contains errors. Application has failed to start... At least one delay - load dependency was not found At least one module has a unresolved import due to a missing export function in a delay-load dependent module Msjava.dll error opening file the system cannot find the file specified (2) And Msjava.dll had a little error symbol next to it and was red. I will rebuild the box I ran this on soon, so let me know if you want any more information. Cheers, Al On Fri, Apr 9, 2010 at 2:52 PM, Brian Carrier <ca...@sl...> wrote: > Can you download depends.exe from: > > http://dependencywalker.com/ > > Run it and open one of the TSK exe files (File -> Open). At the bottom, it should list a bunch of dll files and some may be red (or some other error-looking symbol). Can you report which ones are showing that? > > thanks, > brian > > > > On Apr 8, 2010, at 2:48 PM, Al MailingList wrote: > >> [ sleuthkit-Bugs-2950687 ] Windows binaries not working. >>> Message: 1 >>> Date: Tue, 23 Mar 2010 01:58:42 +0000 >>> From: "SourceForge.net" <no...@so...> >>> Subject: [sleuthkit-developers] [ sleuthkit-Bugs-2950687 ] Windows >>> binaries not working. >>> To: no...@so... >>> Message-ID: <E1N...@sf...> >>> Content-Type: text/plain; charset="UTF-8" >>> >> >> <snip> >> >>> sleuth-win32-3.1.0.zip: On some machines in our relatively homogeneous >>> computer lab, attempting to run TSK tools yields the following error >>> message: "The system cannot execute the specified program" My limited >>> research seems to indicate that an incorrect version of a system DLL could >>> be the culprit (e.g., older kernel32.dll) but I haven't been able to pin >>> down a difference between working and non-working machines, even with >>> Dependency Walker. >> >> Just letting you know I had the same issue on a Windows XP SP2 >> machine. Let me know if you want more info, apologies if things are >> under control. >> >> And also, not sure if anyone has seen this or can reproduce it.... >> >> Once I got things working on the above machine (XP SP2, using TSK >> 3.0.1 instead which worked), I was doing some timeline creation (fls >> -r -m ... ). Everything seemed to be working OK, and then I started up >> a second fls, again with -r and -m but on only a subdirectory (I got >> impatient and figured I didn't really need the whole fs). >> >> This produced a crash (windows error report). I tried it again and on >> different sub directories, but it seemed to keep crashing. When I just >> ran one at a time over the whole drive, no problem. This was on a >> machine I can't really mess about with too much, and I actually don't >> have a good dev setup right now. Is it even possible this is affecting >> things?? If so, and it's not a wacky coincidence or a more subtle >> issue, can someone try and reproduce it? i.e. >> >> fls -r -m C: \\.\C: >> >> and while that is still going: >> >> fls -r -m C: \\.\C: <some sub dir> >> >> where C: is an NTFS drive. >> >> Hope I'm not on crazy pills. >> >> Thanks for the great tools. >> >> Al >> >> ------------------------------------------------------------------------------ >> Download Intel® Parallel Studio Eval >> Try the new software tools for yourself. Speed compiling, find bugs >> proactively, and fine-tune applications for parallel performance. >> See why Intel Parallel Studio got high marks during beta. >> http://p.sf.net/sfu/intel-sw-dev >> _______________________________________________ >> sleuthkit-developers mailing list >> sle...@li... >> https://lists.sourceforge.net/lists/listinfo/sleuthkit-developers > > |
|
From: Brian C. <ca...@sl...> - 2010-04-09 13:52:53
|
Can you download depends.exe from: http://dependencywalker.com/ Run it and open one of the TSK exe files (File -> Open). At the bottom, it should list a bunch of dll files and some may be red (or some other error-looking symbol). Can you report which ones are showing that? thanks, brian On Apr 8, 2010, at 2:48 PM, Al MailingList wrote: > [ sleuthkit-Bugs-2950687 ] Windows binaries not working. >> Message: 1 >> Date: Tue, 23 Mar 2010 01:58:42 +0000 >> From: "SourceForge.net" <no...@so...> >> Subject: [sleuthkit-developers] [ sleuthkit-Bugs-2950687 ] Windows >> binaries not working. >> To: no...@so... >> Message-ID: <E1N...@sf...> >> Content-Type: text/plain; charset="UTF-8" >> > > <snip> > >> sleuth-win32-3.1.0.zip: On some machines in our relatively homogeneous >> computer lab, attempting to run TSK tools yields the following error >> message: "The system cannot execute the specified program" My limited >> research seems to indicate that an incorrect version of a system DLL could >> be the culprit (e.g., older kernel32.dll) but I haven't been able to pin >> down a difference between working and non-working machines, even with >> Dependency Walker. > > Just letting you know I had the same issue on a Windows XP SP2 > machine. Let me know if you want more info, apologies if things are > under control. > > And also, not sure if anyone has seen this or can reproduce it.... > > Once I got things working on the above machine (XP SP2, using TSK > 3.0.1 instead which worked), I was doing some timeline creation (fls > -r -m ... ). Everything seemed to be working OK, and then I started up > a second fls, again with -r and -m but on only a subdirectory (I got > impatient and figured I didn't really need the whole fs). > > This produced a crash (windows error report). I tried it again and on > different sub directories, but it seemed to keep crashing. When I just > ran one at a time over the whole drive, no problem. This was on a > machine I can't really mess about with too much, and I actually don't > have a good dev setup right now. Is it even possible this is affecting > things?? If so, and it's not a wacky coincidence or a more subtle > issue, can someone try and reproduce it? i.e. > > fls -r -m C: \\.\C: > > and while that is still going: > > fls -r -m C: \\.\C: <some sub dir> > > where C: is an NTFS drive. > > Hope I'm not on crazy pills. > > Thanks for the great tools. > > Al > > ------------------------------------------------------------------------------ > Download Intel® Parallel Studio Eval > Try the new software tools for yourself. Speed compiling, find bugs > proactively, and fine-tune applications for parallel performance. > See why Intel Parallel Studio got high marks during beta. > http://p.sf.net/sfu/intel-sw-dev > _______________________________________________ > sleuthkit-developers mailing list > sle...@li... > https://lists.sourceforge.net/lists/listinfo/sleuthkit-developers |
|
From: Al M. <alp...@gm...> - 2010-04-08 18:49:01
|
[ sleuthkit-Bugs-2950687 ] Windows binaries not working. > Message: 1 > Date: Tue, 23 Mar 2010 01:58:42 +0000 > From: "SourceForge.net" <no...@so...> > Subject: [sleuthkit-developers] [ sleuthkit-Bugs-2950687 ] Windows > binaries not working. > To: no...@so... > Message-ID: <E1N...@sf...> > Content-Type: text/plain; charset="UTF-8" > <snip> > sleuth-win32-3.1.0.zip: On some machines in our relatively homogeneous > computer lab, attempting to run TSK tools yields the following error > message: "The system cannot execute the specified program" My limited > research seems to indicate that an incorrect version of a system DLL could > be the culprit (e.g., older kernel32.dll) but I haven't been able to pin > down a difference between working and non-working machines, even with > Dependency Walker. Just letting you know I had the same issue on a Windows XP SP2 machine. Let me know if you want more info, apologies if things are under control. And also, not sure if anyone has seen this or can reproduce it.... Once I got things working on the above machine (XP SP2, using TSK 3.0.1 instead which worked), I was doing some timeline creation (fls -r -m ... ). Everything seemed to be working OK, and then I started up a second fls, again with -r and -m but on only a subdirectory (I got impatient and figured I didn't really need the whole fs). This produced a crash (windows error report). I tried it again and on different sub directories, but it seemed to keep crashing. When I just ran one at a time over the whole drive, no problem. This was on a machine I can't really mess about with too much, and I actually don't have a good dev setup right now. Is it even possible this is affecting things?? If so, and it's not a wacky coincidence or a more subtle issue, can someone try and reproduce it? i.e. fls -r -m C: \\.\C: and while that is still going: fls -r -m C: \\.\C: <some sub dir> where C: is an NTFS drive. Hope I'm not on crazy pills. Thanks for the great tools. Al |
|
From: SourceForge.net <no...@so...> - 2010-04-07 01:51:37
|
Bugs item #2982965, was opened at 2010-04-06 20:45 Message generated for change (Comment added) made by carrier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=2982965&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: attribute reading length bug and patch Initial Comment: Raphael Bousquet from ADF solutions submitted a patch to fs_attr.c: 1105c1105 < blkoffset_inrun) * fs->block_size); --- > blkoffset_inrun) * fs->block_size) - byteoffset_toread; //ADF fix 04/2010 1181a1182 > blkoffset_toread += data_run_cur->len; //ADF fix 04/2010 ---------------------------------------------------------------------- >Comment By: Brian Carrier (carrier) Date: 2010-04-06 20:51 Message: Checked in a variation of the patch in revision 189: Sending branches/sleuthkit-3.1/NEWS.txt Sending branches/sleuthkit-3.1/tsk3/fs/fs_attr.c Sending trunk/NEWS.txt Sending trunk/tsk3/fs/fs_attr.c Thanks! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=2982965&group_id=55685 |
|
From: SourceForge.net <no...@so...> - 2010-04-07 01:45:50
|
Bugs item #2982965, was opened at 2010-04-06 20:45 Message generated for change (Tracker Item Submitted) made by carrier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=2982965&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: attribute reading length bug and patch Initial Comment: Raphael Bousquet from ADF solutions submitted a patch to fs_attr.c: 1105c1105 < blkoffset_inrun) * fs->block_size); --- > blkoffset_inrun) * fs->block_size) - byteoffset_toread; //ADF fix 04/2010 1181a1182 > blkoffset_toread += data_run_cur->len; //ADF fix 04/2010 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=2982965&group_id=55685 |
|
From: SourceForge.net <no...@so...> - 2010-04-07 01:28:27
|
Bugs item #2982426, was opened at 2010-04-05 20:14 Message generated for change (Settings changed) made by carrier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=2982426&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: Slow FAT32 dir listing Initial Comment: If you run fls on a big FAT file system, it is slow because it needs to hunt the file system for the parent directory (in order to populate the metadata address of the ".." entry). In doing so, it ends up trying to load up the orphan directory and this takes a long time. The only good solution seems to be to somehow cache the data because if we just skip the OrpanFiles directory, then if we are listing hte contents of an Orphan Directory, we'll never find the parent directory... ---------------------------------------------------------------------- >Comment By: Brian Carrier (carrier) Date: 2010-04-06 20:28 Message: The code was scanning the entire image even after it found the needed parent. I think the original goal was to fill up the internal cached DB once and then never worry about it, but that is not good for fls. Now, the search stops after the parent is found. Sending branches/sleuthkit-3.1/NEWS.txt Sending branches/sleuthkit-3.1/tsk3/fs/fatfs_dent.c Sending trunk/NEWS.txt Sending trunk/tsk3/fs/fatfs_dent.c Transmitting file data .... Committed revision 188. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=2982426&group_id=55685 |
|
From: SourceForge.net <no...@so...> - 2010-04-06 01:14:52
|
Bugs item #2982426, was opened at 2010-04-05 20:14 Message generated for change (Tracker Item Submitted) made by carrier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=2982426&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: Nobody/Anonymous (nobody) Summary: Slow FAT32 dir listing Initial Comment: If you run fls on a big FAT file system, it is slow because it needs to hunt the file system for the parent directory (in order to populate the metadata address of the ".." entry). In doing so, it ends up trying to load up the orphan directory and this takes a long time. The only good solution seems to be to somehow cache the data because if we just skip the OrpanFiles directory, then if we are listing hte contents of an Orphan Directory, we'll never find the parent directory... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=2982426&group_id=55685 |
|
From: SourceForge.net <no...@so...> - 2010-03-30 21:49:13
|
Feature Requests item #2206306, was opened at 2008-10-28 22:43 Message generated for change (Comment added) made by carrier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477892&aid=2206306&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: function to map name to inode Initial Comment: A more formal function should exist to map the name to an inode / metadata address. ---------------------------------------------------------------------- >Comment By: Brian Carrier (carrier) Date: 2010-03-30 16:49 Message: There is the tsk_fs_ffind() method in tsk3/fs/ffind_lib.c that is not very library friendly and will print the names of the files that use a given metadata address. It would be nicer to have a more general approach that either returns a list of the names or that has a callback so that other programs can find out the names of a metadata address without needing to print the data. tsk_fs_ifind_data() has similar needs for improvement because it too prints the metadata addresses that point to blocks instead of somehow returning the value to the caller and letting it decide how to handle the data (print, process, etc.). tsk_fs_path2inum() was made more library friendly and returns the metadata address, but this is an easier problem because there is only one value that a name can point to. The challenge with mapping blocks to metadata and metadata to a name is that there could be multiple values. ---------------------------------------------------------------------- Comment By: Negin Ahmadian (negin99) Date: 2010-03-30 08:34 Message: Dear Mr.Carrier, Would you please explain more about this issue? What is its usability? Could you please give me an example. Actually I'm doing my graduate thesis about digital forensics field and need to implement some new features for an open source tool. I've chosen Autopsy and TSK. I read each requested feature detail carefully but couldn't decide what to implement yet. I'm familiar with etx3 file system and TSK data structures. I want to know if you could give me a suggestion. Thanks a lot in advance. Best, Negin ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477892&aid=2206306&group_id=55685 |
|
From: SourceForge.net <no...@so...> - 2010-03-30 13:34:52
|
Feature Requests item #2206306, 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=2206306&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: function to map name to inode Initial Comment: A more formal function should exist to map the name to an inode / metadata address. ---------------------------------------------------------------------- Comment By: Negin Ahmadian (negin99) Date: 2010-03-30 18:04 Message: Dear Mr.Carrier, Would you please explain more about this issue? What is its usability? Could you please give me an example. Actually I'm doing my graduate thesis about digital forensics field and need to implement some new features for an open source tool. I've chosen Autopsy and TSK. I read each requested feature detail carefully but couldn't decide what to implement yet. I'm familiar with etx3 file system and TSK data structures. I want to know if you could give me a suggestion. Thanks a lot in advance. Best, Negin ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477892&aid=2206306&group_id=55685 |
|
From: SourceForge.net <no...@so...> - 2010-03-29 12:54:40
|
Bugs item #2978574, was opened at 2010-03-29 14:54 Message generated for change (Tracker Item Submitted) made by wlet You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=2978574&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: Wlet (wlet) Assigned to: Nobody/Anonymous (nobody) Summary: Feature Request: Please add XFS Support Initial Comment: Hi, please add XFS Support for TSK. THX wlet ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=2978574&group_id=55685 |
|
From: SourceForge.net <no...@so...> - 2010-03-24 01:46:44
|
Bugs item #2975624, was opened at 2010-03-23 20:46 Message generated for change (Tracker Item Submitted) made by carrier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=2975624&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: Nobody/Anonymous (nobody) Summary: NTFS-3G issues? Initial Comment: Posted to sleuthkit-users on 3/4/10 by Adrian Shaw Hi I'm using TSK 3.1.0 on OpenSuSe 10.3, installed from source. It appears that fls isn't listing deleted files on media formatted with the ntfs-3g package. I used a 2GB CF card, wiped it, formatted it with linux fdisk then laid down an ntfs filesystem using the mkfs.ntfs utility from the ntfs-3g project. I copied a load of files to the card, then deleted about 30 of them. Then I used fls to try and view the metadata for the deleted files: fls -d -r -i raw -f ntfs -o 62 /dev/sdd No results are returned from this command. So I re-ran the command but modify it to show all files: fls -r -i raw -f ntfs -o 62 /dev/sdd I get the expected output - the metadata is listed for the live files. I then use ntfsdelete to try and get information regarding the deleted files on the card: ntfsundelete -f /dev/sdd1 Volume is dirty. Forced to continue. Inode Flags %age Date Size Filename --------------------------------------------------------------- 16 F... 0% 2010-01-10 0 <none> 17 F... 0% 2010-01-10 0 <none> 18 F... 0% 2010-01-10 0 <none> 19 F... 0% 2010-01-10 0 <none> 20 F... 0% 2010-01-10 0 <none> 21 F... 0% 2010-01-10 0 <none> 22 F... 0% 2010-01-10 0 <none> 23 F... 0% 2010-01-10 0 <none> 1453 D... 0% 2010-01-16 0 <none> 1455 FN.. 100% 2006-11-16 1554574 <none> 1456 D... 0% 2010-01-16 0 <none> 1457 FN.. 100% 2006-11-16 1568011 <none> 1458 FN.. 100% 2006-11-16 1551851 <none> 1459 FN.. 100% 2006-11-16 1602861 <none> 1461 FN.. 100% 2006-11-16 1568559 <none> 1462 FN.. 100% 2006-11-16 1565797 <none> 1482 D... 0% 2010-01-16 0 <none> 2620 D... 0% 2010-01-16 0 <none> 2621 FN.. 100% 2006-11-16 2195587 <none> 2622 FN.. 100% 2006-11-16 1533953 <none> 2623 FN.. 100% 2006-11-16 1559211 <none> 2624 D... 0% 2010-01-16 0 <none> 2625 FN.. 100% 2006-11-16 1561141 <none> 2626 FN.. 100% 2006-11-16 1492597 <none> 2627 FN.. 100% 2006-11-16 1535152 <none> 2628 FN.. 100% 2006-11-16 1475406 <none> 2629 FN.. 100% 2006-11-16 1537154 <none> 2630 FN.. 100% 2006-11-16 1524184 <none> 2631 FN.. 100% 2006-11-16 1571648 <none> 2632 D... 0% 2010-01-16 0 <none> 2633 FN.. 100% 2006-11-16 1591611 <none> 2634 FN.. 100% 2006-11-16 1577103 <none> 2635 FN.. 100% 2006-11-16 1580217 <none> 2636 FN.. 100% 2006-11-16 2450007 <none> 2637 FN.. 100% 2006-11-16 1839617 <none> 2638 FN.. 100% 2006-11-16 1734110 <none> 2639 FN.. 100% 2006-11-16 1746931 <none> 2640 D... 0% 2010-01-16 0 <none> 2641 FN.. 100% 2006-11-16 2481670 <none> 2642 FN.. 100% 2006-11-16 2451247 <none> 2643 FN.. 100% 2006-11-16 1727085 <none> 2644 FN.. 100% 2006-11-16 1257376 <none> 2645 FN.. 100% 2006-11-16 1642654 <none> 2646 FN.. 100% 2006-11-16 852610 <none> 2647 FN.. 100% 2006-11-16 2441440 <none> 2648 FN.. 100% 2006-11-16 1672247 <none> 2649 FN.. 100% 2006-11-16 2173221 <none> 2650 FN.. 100% 2006-11-16 2278516 <none> 2651 D... 0% 2010-01-16 0 <none> Files with potentially recoverable content: 33 So, there is some inconsistency with the "Date" output and no filenames are listed, however there is apparently information regarding deleted files. Next I just concentrate on the first potentially recoverable file which is listed as inode 1455. First I use ntfsundelete to recover the file, this is successful. I then re-run fls -r and grep the output for "1455" to see if fls has wrongly identified the file as being an active file...no result. Then I try istat on that inode: istat -i raw -f ntfs -o 62 /dev/sdd 1455 MFT Entry Header Values: Entry: 1455 Sequence: 5 $LogFile Sequence Number: 0 Not Allocated File Links: 0 $STANDARD_INFORMATION Attribute Values: Flags: Owner ID: 0 Security ID: 0 () Created: Sat Jan 16 14:38:49 2010 File Modified: Thu Nov 16 22:47:02 2006 MFT Modified: Thu Nov 16 22:47:02 2006 Accessed: Tue Jun 23 01:00:00 2009 Attributes: Type: $STANDARD_INFORMATION (16-0) Name: N/A Resident size: 48 Type: $SECURITY_DESCRIPTOR (80-1) Name: N/A Resident size: 80 Type: $DATA (128-2) Name: $Data Non-Resident size: 1554574 117046...117805 (Data runs truncated for ease of viewing) Then I use icat to output the allocated clusters...this is successful. I would guess that most of the inconsistencies are as a result of how the ntfs-3g project has implemented various features of ntfs. Regards Adrian Shaw ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=2975624&group_id=55685 |
|
From: SourceForge.net <no...@so...> - 2010-03-24 01:40:09
|
Bugs item #2975613, was opened at 2010-03-23 20:40 Message generated for change (Tracker Item Submitted) made by carrier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=2975613&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: Nobody/Anonymous (nobody) Summary: 4K FAT sectors don't seem to be supported. Initial Comment: >From Thai Duong (April 2009) Recently I acquired a removable USB thumb drive containing one single FAT32 file system which most of the tools in The Sleuth Kit fail to analyze it. As far as I know, the reason is this FAT32 file system uses a 4096-bytes sector, while The Sleuth Kit assumps a sector to be 512 bytes. Is it that the case? Please correct me if I'm wrong. Since each sector is 4096-byte, the 510 and 511 bytes of the first sector don't contain the signagure 0x55AA. This makes tools like icat or istat stop working. When I write the signature to these two bytes, everything is working again except fsstat who keeps complaining: FILE SYSTEM INFORMATION -------------------------------------------- File System Type: FAT32 OEM Name: MSWIN4.1 Volume ID: 0x12345678 Volume Label (Boot Sector): NO NAME Volume Label (Root Directory): File System Type Label: FAT32 Error reading image file (tsk_fs_read_block: length 512 not a multiple of 4096) (fatfs_fsstat: TSK_FS_TYPE_FAT32 FSINFO block: 1) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=2975613&group_id=55685 |
|
From: SourceForge.net <no...@so...> - 2010-03-24 01:10:36
|
Feature Requests item #2288736, was opened at 2008-11-15 00:18 Message generated for change (Comment added) made by carrier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477900&aid=2288736&group_id=55687 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: Brian Carrier (carrier) Assigned to: Nobody/Anonymous (nobody) Summary: Better reports Initial Comment: Generate HTML or some other non-ASCII form of reports. ---------------------------------------------------------------------- >Comment By: Brian Carrier (carrier) Date: 2010-03-23 20:10 Message: Yea, the request was meant to cover all of the reports. The file analysis mode is a good place to start. I would open the question to the users on sleuthkit-users to see what they would like to see. ---------------------------------------------------------------------- Comment By: Negin Ahmadian (negin99) Date: 2010-03-04 02:21 Message: Hi! I'm eager to help with this issue but I have some questions about it: First, do you mean the reports that generated in file analysis mode? (ASCII, HEX, ASCII string) and second, would you please explain more in detail which format is preferable and give me some hints? Thanks a lot in advance and hope that I could help. Best, Negin ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477900&aid=2288736&group_id=55687 |
|
From: SourceForge.net <no...@so...> - 2010-03-24 00:59:52
|
Bugs item #2900761, was opened at 2009-11-19 16:56 Message generated for change (Comment added) made by carrier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=2900761&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: ISO Infinite Loop Initial Comment: Rob Meijer reported an infinite loop issue with ISO CDs. He sent me some logs that I need to parse through and debug. ---------------------------------------------------------------------- >Comment By: Brian Carrier (carrier) Date: 2010-03-23 19:59 Message: The fix seems to have resolved the issue. ---------------------------------------------------------------------- Comment By: Brian Carrier (carrier) Date: 2009-11-20 16:07 Message: Added sanity checks before starting the search for FAT parent directories. The corrupt ISO image is being detected as FAT. Sending trunk/CHANGES.txt Sending trunk/tsk3/fs/fatfs_dent.c Transmitting file data .. Committed revision 129. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=2900761&group_id=55685 |
|
From: SourceForge.net <no...@so...> - 2010-03-24 00:59:07
|
Bugs item #2975245, was opened at 2010-03-23 09:12 Message generated for change (Settings changed) made by carrier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=2975245&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: sorter Group: None >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Brian Carrier (carrier) Assigned to: Brian Carrier (carrier) Summary: Misleading conclusion about realloc data Initial Comment: Andrew Hoog reported an issue that led to some confusion. He has an NTFS image with a deleted exe name that now points to an allocated MFT entry (with a JPG). It was reported as an extension mismatch. sorter should ignore realloc entries since the content will be found from another allocated name. ---------------------------------------------------------------------- >Comment By: Brian Carrier (carrier) Date: 2010-03-23 19:59 Message: Sending branches/sleuthkit-3.1/NEWS.txt Sending branches/sleuthkit-3.1/tools/sorter/sorter.base Sending trunk/NEWS.txt Sending trunk/tools/sorter/sorter.base Transmitting file data .... Committed revision 182. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=2975245&group_id=55685 |
|
From: SourceForge.net <no...@so...> - 2010-03-23 14:12:12
|
Bugs item #2975245, was opened at 2010-03-23 09:12 Message generated for change (Tracker Item Submitted) made by carrier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=2975245&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: sorter Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Brian Carrier (carrier) Assigned to: Brian Carrier (carrier) Summary: Misleading conclusion about realloc data Initial Comment: Andrew Hoog reported an issue that led to some confusion. He has an NTFS image with a deleted exe name that now points to an allocated MFT entry (with a JPG). It was reported as an extension mismatch. sorter should ignore realloc entries since the content will be found from another allocated name. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=2975245&group_id=55685 |
|
From: SourceForge.net <no...@so...> - 2010-03-23 03:19:46
|
Bugs item #2954448, was opened at 2010-02-18 16:16 Message generated for change (Comment added) made by carrier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=2954448&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: Brian Carrier (carrier) Assigned to: Brian Carrier (carrier) Summary: Incorporate Debian fixes Initial Comment: The Debian package manager (Cristian Greco) fixed some typos and compile errors. Work them into the code: http://git.debian.org/?p=forensics/sleuthkit.git;a=summary ---------------------------------------------------------------------- >Comment By: Brian Carrier (carrier) Date: 2010-03-22 22:19 Message: Sending branches/sleuthkit-3.1/NEWS.txt Sending branches/sleuthkit-3.1/man/blkcalc.1 Sending branches/sleuthkit-3.1/man/blkcat.1 Sending branches/sleuthkit-3.1/man/blkls.1 Sending branches/sleuthkit-3.1/man/blkstat.1 Sending branches/sleuthkit-3.1/man/ffind.1 Sending branches/sleuthkit-3.1/man/fls.1 Sending branches/sleuthkit-3.1/man/fsstat.1 Sending branches/sleuthkit-3.1/man/hfind.1 Sending branches/sleuthkit-3.1/man/icat.1 Sending branches/sleuthkit-3.1/man/ifind.1 Sending branches/sleuthkit-3.1/man/ils.1 Sending branches/sleuthkit-3.1/man/img_cat.1 Sending branches/sleuthkit-3.1/man/img_stat.1 Sending branches/sleuthkit-3.1/man/istat.1 Sending branches/sleuthkit-3.1/man/jcat.1 Sending branches/sleuthkit-3.1/man/jls.1 Sending branches/sleuthkit-3.1/man/mactime.1 Sending branches/sleuthkit-3.1/man/mmcat.1 Sending branches/sleuthkit-3.1/man/mmls.1 Sending branches/sleuthkit-3.1/man/mmstat.1 Sending branches/sleuthkit-3.1/man/sigfind.1 Sending branches/sleuthkit-3.1/man/sorter.1 Sending branches/sleuthkit-3.1/tools/fstools/Makefile.am Sending branches/sleuthkit-3.1/tools/hashtools/Makefile.am Sending branches/sleuthkit-3.1/tools/imgtools/Makefile.am Sending branches/sleuthkit-3.1/tools/vstools/Makefile.am Sending branches/sleuthkit-3.1/tsk3/fs/ntfs.c Sending branches/sleuthkit-3.1/tsk3/vs/mm_part.c Sending trunk/NEWS.txt Sending trunk/man/blkcalc.1 Sending trunk/man/blkcat.1 Sending trunk/man/blkls.1 Sending trunk/man/blkstat.1 Sending trunk/man/ffind.1 Sending trunk/man/fls.1 Sending trunk/man/fsstat.1 Sending trunk/man/hfind.1 Sending trunk/man/icat.1 Sending trunk/man/ifind.1 Sending trunk/man/ils.1 Sending trunk/man/img_cat.1 Sending trunk/man/img_stat.1 Sending trunk/man/istat.1 Sending trunk/man/jcat.1 Sending trunk/man/jls.1 Sending trunk/man/mactime.1 Sending trunk/man/mmcat.1 Sending trunk/man/mmls.1 Sending trunk/man/mmstat.1 Sending trunk/man/sigfind.1 Sending trunk/man/sorter.1 Sending trunk/tools/fstools/Makefile.am Sending trunk/tools/hashtools/Makefile.am Sending trunk/tools/imgtools/Makefile.am Sending trunk/tools/vstools/Makefile.am Sending trunk/tsk3/fs/fatfs_dent.c Sending trunk/tsk3/fs/ntfs.c Sending trunk/tsk3/vs/mm_part.c Transmitting file data ........................................................... Committed revision 181. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=2954448&group_id=55685 |
|
From: SourceForge.net <no...@so...> - 2010-03-23 01:58:42
|
Bugs item #2950687, was opened at 2010-02-12 11:38 Message generated for change (Settings changed) made by carrier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=2950687&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: Brian Carrier (carrier) >Assigned to: Brian Carrier (carrier) Summary: Windows binaries not working. Initial Comment: >From Gregg Gunsch: Per the instruction on the bug tracker page, I'm sending this to the sleuthkit-users list first. Does anybody else see this problem or know of a simple solution? sleuth-win32-3.1.0.zip: On some machines in our relatively homogeneous computer lab, attempting to run TSK tools yields the following error message: "The system cannot execute the specified program" My limited research seems to indicate that an incorrect version of a system DLL could be the culprit (e.g., older kernel32.dll) but I haven't been able to pin down a difference between working and non-working machines, even with Dependency Walker. The files were extracted from the .zip archive and placed into a directory in "C:\Program Files", preserving the hierarchy found in the archive. The path was added to the environment variable, and the commands are being found (e.g., "which istat" locates it). They just aren't successfully being run. I even tried copying the DLLs that came with TSK into the system32 folder, but no help. We are running WinXP Pro, SP2 and SP3. Some SP2 machines run TSK just fine, as do the SP3 versions (and yes, I'm in the process of updating them all). I've also hashed the TSK files on a working system and compared to those on a non-working machine - they are identical. Is there a way to produce a more portable collection of executables that are less target-system dependent? Is there something I should be doing with the manifest so that the dependencies are satisfied? Should I be compiling the source myself instead of using the build in the .zip file? It's been years since I've done development, and a lot seems to have changed, so there may be some simple steps that I'm just overlooking right now. Thanks for your assistance, [[ other offline e-mails exist. Other versions of visual studio are on the machine ]] ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=2950687&group_id=55685 |
|
From: SourceForge.net <no...@so...> - 2010-03-23 01:53:56
|
Bugs item #2950986, was opened at 2010-02-12 20:41 Message generated for change (Settings changed) made by carrier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=2950986&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: 7 Private: No Submitted By: Brian Carrier (carrier) Assigned to: Brian Carrier (carrier) Summary: Autopsy needs to support 0-sized HFS directories Initial Comment: The size of a directory needs to be figured out. HFS doesn't store this info and TSK doesn't estimate it. This impacts Autopsy. ---------------------------------------------------------------------- >Comment By: Brian Carrier (carrier) Date: 2010-03-22 20:53 Message: Sending trunk/CHANGES.txt Sending trunk/configure Sending trunk/lib/File.pm Transmitting file data ... Committed revision 33. ---------------------------------------------------------------------- Comment By: Brian Carrier (carrier) Date: 2010-03-22 20:01 Message: It is true that HFS directories take 0 bytes of blocks because their contents are in the B-trees. Therefore, Autopsy should be fixed. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=2950986&group_id=55685 |
|
From: SourceForge.net <no...@so...> - 2010-03-23 01:26:11
|
Bugs item #2941813, was opened at 2010-01-28 15:25 Message generated for change (Comment added) made by carrier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=2941813&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: Rob (robjoyce) Assigned to: Brian Carrier (carrier) Summary: HFSX case sensitivity internal constants named backwards Initial Comment: The internal constants in tsk_hfs.h, HFS_BT_HEAD_COMP_SENS and HFS_BT_HEAD_COMP_INSENS, have swapped names: the value for HFS_BT_HEAD_COMP_SENS is currently 0xCF ("case folding") and HFS_BT_HEAD_COMP_INSENS is 0xBC ("binary compare"), but they should be reversed. But then the code that tests against these constants is also backward: it sets hfs->is_case_sensitive to 1 if the flag matches HFS_BT_HEAD_COMP_INSENS and 0 if it matches HFS_BT_HEAD_COMP_SENS. So the net effect is that hfs->is_case_sensitive is set correctly. But someone reading the code, or trying to use the HFS_BT_HEAD_COMP_* constants directly, would be very confused. ---------------------------------------------------------------------- >Comment By: Brian Carrier (carrier) Date: 2010-03-22 20:26 Message: Sending branches/sleuthkit-3.1/NEWS.txt Sending branches/sleuthkit-3.1/tsk3/fs/hfs.c Sending branches/sleuthkit-3.1/tsk3/fs/tsk_hfs.h Sending trunk/NEWS.txt Sending trunk/tsk3/fs/hfs.c Sending trunk/tsk3/fs/tsk_hfs.h Transmitting file data ...... Committed revision 180. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=2941813&group_id=55685 |
|
From: SourceForge.net <no...@so...> - 2010-03-23 01:03:13
|
Bugs item #2941813, was opened at 2010-01-28 15:25 Message generated for change (Settings changed) made by carrier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=2941813&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 (robjoyce) >Assigned to: Brian Carrier (carrier) Summary: HFSX case sensitivity internal constants named backwards Initial Comment: The internal constants in tsk_hfs.h, HFS_BT_HEAD_COMP_SENS and HFS_BT_HEAD_COMP_INSENS, have swapped names: the value for HFS_BT_HEAD_COMP_SENS is currently 0xCF ("case folding") and HFS_BT_HEAD_COMP_INSENS is 0xBC ("binary compare"), but they should be reversed. But then the code that tests against these constants is also backward: it sets hfs->is_case_sensitive to 1 if the flag matches HFS_BT_HEAD_COMP_INSENS and 0 if it matches HFS_BT_HEAD_COMP_SENS. So the net effect is that hfs->is_case_sensitive is set correctly. But someone reading the code, or trying to use the HFS_BT_HEAD_COMP_* constants directly, would be very confused. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=2941813&group_id=55685 |
|
From: SourceForge.net <no...@so...> - 2010-03-23 01:01:18
|
Bugs item #2950986, was opened at 2010-02-12 20:41 Message generated for change (Comment added) made by carrier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=2950986&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: 7 Private: No Submitted By: Brian Carrier (carrier) >Assigned to: Brian Carrier (carrier) >Summary: Autopsy needs to support 0-sized HFS directories Initial Comment: The size of a directory needs to be figured out. HFS doesn't store this info and TSK doesn't estimate it. This impacts Autopsy. ---------------------------------------------------------------------- >Comment By: Brian Carrier (carrier) Date: 2010-03-22 20:01 Message: It is true that HFS directories take 0 bytes of blocks because their contents are in the B-trees. Therefore, Autopsy should be fixed. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=2950986&group_id=55685 |
|
From: SourceForge.net <no...@so...> - 2010-03-23 00:59:42
|
Bugs item #2954448, was opened at 2010-02-18 16:16 Message generated for change (Settings changed) made by carrier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=2954448&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: Incorporate Debian fixes Initial Comment: The Debian package manager (Cristian Greco) fixed some typos and compile errors. Work them into the code: http://git.debian.org/?p=forensics/sleuthkit.git;a=summary ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=477889&aid=2954448&group_id=55685 |
1 message has been excluded from this view by a project administrator.
