Thread: [sleuthkit-users] TSK-4.4 and SlackFiles
Brought to you by:
carrier
Menu
▾
▴
sleuthkit-users
|
From: Luís F. N. <lfc...@gm...> - 2017-01-31 12:04:42
|
Hi folks, I am upgrading to tsk-4.4 to benefit from the new support to slackfiles from java bindings. But I noticed some slackfiles larger than the cluster size (4k) are created in database. Some of them have megabytes of size and its contents are accessible. Is it expected to have slackfiles larger than cluster size? Could someone explain? Thanks, Luis Nassif |
|
From: Brian C. <ca...@sl...> - 2017-01-31 15:23:27
|
Hi Luis, My guess is that it's a file that has preallocated a large amount of space, but that has not fully used it yet. NTFS allows this. If you read the file, TSK will only show you the space that is used. Reading the slack, gives you the rest. If you run 'istat' on one of these files and send it along, we can confirm. thanks, brian On Tue, Jan 31, 2017 at 7:04 AM, Luís Filipe Nassif <lfc...@gm...> wrote: > Hi folks, > > I am upgrading to tsk-4.4 to benefit from the new support to slackfiles > from java bindings. But I noticed some slackfiles larger than the cluster > size (4k) are created in database. Some of them have megabytes of size and > its contents are accessible. Is it expected to have slackfiles larger than > cluster size? Could someone explain? > > Thanks, > Luis Nassif > > ------------------------------------------------------------ > ------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, SlashDot.org! http://sdm.link/slashdot > _______________________________________________ > sleuthkit-users mailing list > https://lists.sourceforge.net/lists/listinfo/sleuthkit-users > http://www.sleuthkit.org > > |
|
From: Luís F. N. <lfc...@gm...> - 2017-01-31 15:55:30
|
Hi Brian, Thank you very much for your attention. The output of FsContent.getMetaDataText() (equals to istat right?) is below. The system.LOG-slack size is 2.026.496 bytes and system.LOG size is 1024 bytes. details of /img_PC-HP.dd/vol_vol2/WINDOWS/system32/config/system.LOG-slack MFT Entry Header Values: Entry: 4106 Sequence: 1 $LogFile Sequence Number: 79246281526 Allocated File Links: 1 $STANDARD_INFORMATION Attribute Values: Flags: Hidden, Archive Owner ID: 0 Security ID: 281 (S-1-5-32-544) Last User Journal Update Sequence Number: 105272096 Created: 2004-09-02 08:00:12.000000000 (Hora oficial do Brasil) File Modified: 2011-09-16 14:33:38.375000000 (Hora oficial do Brasil) MFT Modified: 2011-09-16 14:33:38.375000000 (Hora oficial do Brasil) Accessed: 2011-09-16 14:33:38.187500000 (Hora oficial do Brasil) $FILE_NAME Attribute Values: Flags: Hidden, Archive Name: system.LOG Parent MFT Entry: 3982 Sequence: 2 Allocated Size: 4096 Actual Size: 1024 Created: 2004-09-02 08:00:12.000000000 (Hora oficial do Brasil) File Modified: 2004-09-02 08:00:12.000000000 (Hora oficial do Brasil) MFT Modified: 2004-09-02 08:00:12.000000000 (Hora oficial do Brasil) Accessed: 2004-09-02 08:00:12.000000000 (Hora oficial do Brasil) $ATTRIBUTE_LIST Attribute Values: Type: 16-0 MFT Entry: 4106 VCN: 0 Type: 48-4 MFT Entry: 4106 VCN: 0 Type: 128-0 MFT Entry: 40678 VCN: 0 Attributes: Type: $STANDARD_INFORMATION (16-0) Name: N/A Resident size: 72 Type: $ATTRIBUTE_LIST (32-5) Name: N/A Resident size: 96 Type: $FILE_NAME (48-4) Name: N/A Resident size: 86 Type: $DATA (128-6) Name: N/A Non-Resident size: 1024 init_size: 1024 847844 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 2017-01-31 12:56 GMT-02:00 Brian Carrier <ca...@sl...>: > Hi Luis, > > My guess is that it's a file that has preallocated a large amount of > space, but that has not fully used it yet. NTFS allows this. If you read > the file, TSK will only show you the space that is used. Reading the > slack, gives you the rest. > > If you run 'istat' on one of these files and send it along, we can confirm. > > thanks, > brian > > > On Tue, Jan 31, 2017 at 7:04 AM, Luís Filipe Nassif <lfc...@gm...> > wrote: > >> Hi folks, >> >> I am upgrading to tsk-4.4 to benefit from the new support to slackfiles >> from java bindings. But I noticed some slackfiles larger than the cluster >> size (4k) are created in database. Some of them have megabytes of size and >> its contents are accessible. Is it expected to have slackfiles larger than >> cluster size? Could someone explain? >> >> Thanks, >> Luis Nassif >> >> ------------------------------------------------------------ >> ------------------ >> Check out the vibrant tech community on one of the world's most >> engaging tech sites, SlashDot.org! http://sdm.link/slashdot >> _______________________________________________ >> sleuthkit-users mailing list >> https://lists.sourceforge.net/lists/listinfo/sleuthkit-users >> http://www.sleuthkit.org >> >> > |
|
From: Brian C. <ca...@sl...> - 2017-01-31 20:21:05
|
Yea, this looks like "VDL Slack". Same general idea as in Issue 466 ( https://github.com/sleuthkit/sleuthkit/issues/466), but in this case the file has 1K of initialized size. I suppose this "slack" file is a bit wasted though because no blocks were allocated to it. So, there will be no real content for it. I'll make an internal story to keep track of this and maybe Ann will be able to take a look at not making these if they are going to be all for address 0. On Tue, Jan 31, 2017 at 10:55 AM, Luís Filipe Nassif <lfc...@gm...> wrote: > Hi Brian, > > Thank you very much for your attention. The output of > FsContent.getMetaDataText() (equals to istat right?) is below. The > system.LOG-slack size is 2.026.496 bytes and system.LOG size is 1024 bytes. > > details of /img_PC-HP.dd/vol_vol2/WINDOWS/system32/config/system.LOG-slack > > MFT Entry Header Values: > Entry: 4106 Sequence: 1 > $LogFile Sequence Number: 79246281526 > Allocated File > Links: 1 > > $STANDARD_INFORMATION Attribute Values: > Flags: Hidden, Archive > Owner ID: 0 > Security ID: 281 (S-1-5-32-544) > Last User Journal Update Sequence Number: 105272096 > Created: 2004-09-02 08:00:12.000000000 (Hora oficial do Brasil) > File Modified: 2011-09-16 14:33:38.375000000 (Hora oficial do Brasil) > MFT Modified: 2011-09-16 14:33:38.375000000 (Hora oficial do Brasil) > Accessed: 2011-09-16 14:33:38.187500000 (Hora oficial do Brasil) > > $FILE_NAME Attribute Values: > Flags: Hidden, Archive > Name: system.LOG > Parent MFT Entry: 3982 Sequence: 2 > Allocated Size: 4096 Actual Size: 1024 > Created: 2004-09-02 08:00:12.000000000 (Hora oficial do Brasil) > File Modified: 2004-09-02 08:00:12.000000000 (Hora oficial do Brasil) > MFT Modified: 2004-09-02 08:00:12.000000000 (Hora oficial do Brasil) > Accessed: 2004-09-02 08:00:12.000000000 (Hora oficial do Brasil) > > $ATTRIBUTE_LIST Attribute Values: > Type: 16-0 MFT Entry: 4106 VCN: 0 > Type: 48-4 MFT Entry: 4106 VCN: 0 > Type: 128-0 MFT Entry: 40678 VCN: 0 > > Attributes: > Type: $STANDARD_INFORMATION (16-0) Name: N/A Resident size: 72 > Type: $ATTRIBUTE_LIST (32-5) Name: N/A Resident size: 96 > Type: $FILE_NAME (48-4) Name: N/A Resident size: 86 > Type: $DATA (128-6) Name: N/A Non-Resident size: 1024 init_size: > 1024 > 847844 0 0 0 0 0 0 0 > 0 0 0 0 0 0 0 0 > 0 0 0 0 0 0 0 0 > 0 0 0 0 0 0 0 0 > 0 0 0 0 0 0 0 0 > 0 0 0 0 0 0 0 0 > 0 0 0 0 0 0 0 0 > 0 0 0 0 0 0 0 0 > 0 0 0 0 0 0 0 0 > 0 0 0 0 0 0 0 0 > 0 0 0 0 0 0 0 0 > 0 0 0 0 0 0 0 0 > 0 0 0 0 0 0 0 0 > 0 0 0 0 0 0 0 0 > 0 0 0 0 0 0 0 0 > 0 0 0 0 0 0 0 0 > 0 0 0 0 0 0 0 0 > 0 0 0 0 0 0 0 0 > 0 0 0 0 0 0 0 0 > 0 0 0 0 0 0 0 0 > 0 0 0 0 0 0 0 0 > 0 0 0 0 0 0 0 0 > 0 0 0 0 0 0 0 0 > 0 0 0 0 0 0 0 0 > 0 0 0 0 0 0 0 0 > 0 0 0 0 0 0 0 0 > 0 0 0 0 0 0 0 0 > 0 0 0 0 0 0 0 0 > 0 0 0 0 0 0 0 0 > 0 0 0 0 0 0 0 0 > 0 0 0 0 0 0 0 0 > 0 0 0 0 0 0 0 0 > 0 0 0 0 0 0 0 0 > 0 0 0 0 0 0 0 0 > 0 0 0 0 0 0 0 0 > 0 0 0 0 0 0 0 0 > 0 0 0 0 0 0 0 0 > 0 0 0 0 0 0 0 0 > 0 0 0 0 0 0 0 0 > 0 0 0 0 0 0 0 0 > 0 0 0 0 0 0 0 0 > 0 0 0 0 0 0 0 0 > 0 0 0 0 0 0 0 0 > 0 0 0 0 0 0 0 0 > 0 0 0 0 0 0 0 0 > 0 0 0 0 0 0 0 0 > 0 0 0 0 0 0 0 0 > 0 0 0 0 0 0 0 0 > 0 0 0 0 0 0 0 0 > 0 0 0 0 0 0 0 0 > 0 0 0 0 0 0 0 0 > 0 0 0 0 0 0 0 0 > 0 0 0 0 0 0 0 0 > 0 0 0 0 0 0 0 0 > 0 0 0 0 0 0 0 0 > 0 0 0 0 0 0 0 0 > 0 0 0 0 0 0 0 0 > 0 0 0 0 0 0 0 0 > 0 0 0 0 0 0 0 0 > 0 0 0 0 0 0 0 0 > 0 0 0 0 0 0 0 0 > 0 0 0 0 0 0 0 > > 2017-01-31 12:56 GMT-02:00 Brian Carrier <ca...@sl...>: > >> Hi Luis, >> >> My guess is that it's a file that has preallocated a large amount of >> space, but that has not fully used it yet. NTFS allows this. If you read >> the file, TSK will only show you the space that is used. Reading the >> slack, gives you the rest. >> >> If you run 'istat' on one of these files and send it along, we can >> confirm. >> >> thanks, >> brian >> >> >> On Tue, Jan 31, 2017 at 7:04 AM, Luís Filipe Nassif <lfc...@gm...> >> wrote: >> >>> Hi folks, >>> >>> I am upgrading to tsk-4.4 to benefit from the new support to slackfiles >>> from java bindings. But I noticed some slackfiles larger than the cluster >>> size (4k) are created in database. Some of them have megabytes of size and >>> its contents are accessible. Is it expected to have slackfiles larger than >>> cluster size? Could someone explain? >>> >>> Thanks, >>> Luis Nassif >>> >>> ------------------------------------------------------------ >>> ------------------ >>> Check out the vibrant tech community on one of the world's most >>> engaging tech sites, SlashDot.org! http://sdm.link/slashdot >>> _______________________________________________ >>> sleuthkit-users mailing list >>> https://lists.sourceforge.net/lists/listinfo/sleuthkit-users >>> http://www.sleuthkit.org >>> >>> >> > |
|
From: Brian C. <ca...@sl...> - 2017-01-31 20:12:21
|
Actually, making this decision could incur some significant overhead for a step that (at least in Autopsy) we try to keep as fast as possible. Is your application impacted by the fact that there is a large and empty slack file or were you just curious if it was a bug? On Tue, Jan 31, 2017 at 2:54 PM, Brian Carrier <ca...@sl...> wrote: > Yea, this looks like "VDL Slack". Same general idea as in Issue 466 ( > https://github.com/sleuthkit/sleuthkit/issues/466), but in this case the > file has 1K of initialized size. > > I suppose this "slack" file is a bit wasted though because no blocks were > allocated to it. So, there will be no real content for it. > > I'll make an internal story to keep track of this and maybe Ann will be > able to take a look at not making these if they are going to be all for > address 0. > > > > On Tue, Jan 31, 2017 at 10:55 AM, Luís Filipe Nassif <lfc...@gm...> > wrote: > >> Hi Brian, >> >> Thank you very much for your attention. The output of >> FsContent.getMetaDataText() (equals to istat right?) is below. The >> system.LOG-slack size is 2.026.496 bytes and system.LOG size is 1024 bytes. >> >> details of /img_PC-HP.dd/vol_vol2/WINDOWS/system32/config/system.LOG- >> slack >> >> MFT Entry Header Values: >> Entry: 4106 Sequence: 1 >> $LogFile Sequence Number: 79246281526 >> Allocated File >> Links: 1 >> >> $STANDARD_INFORMATION Attribute Values: >> Flags: Hidden, Archive >> Owner ID: 0 >> Security ID: 281 (S-1-5-32-544) >> Last User Journal Update Sequence Number: 105272096 >> Created: 2004-09-02 08:00:12.000000000 (Hora oficial do Brasil) >> File Modified: 2011-09-16 14:33:38.375000000 (Hora oficial do Brasil) >> MFT Modified: 2011-09-16 14:33:38.375000000 (Hora oficial do Brasil) >> Accessed: 2011-09-16 14:33:38.187500000 (Hora oficial do Brasil) >> >> $FILE_NAME Attribute Values: >> Flags: Hidden, Archive >> Name: system.LOG >> Parent MFT Entry: 3982 Sequence: 2 >> Allocated Size: 4096 Actual Size: 1024 >> Created: 2004-09-02 08:00:12.000000000 (Hora oficial do Brasil) >> File Modified: 2004-09-02 08:00:12.000000000 (Hora oficial do Brasil) >> MFT Modified: 2004-09-02 08:00:12.000000000 (Hora oficial do Brasil) >> Accessed: 2004-09-02 08:00:12.000000000 (Hora oficial do Brasil) >> >> $ATTRIBUTE_LIST Attribute Values: >> Type: 16-0 MFT Entry: 4106 VCN: 0 >> Type: 48-4 MFT Entry: 4106 VCN: 0 >> Type: 128-0 MFT Entry: 40678 VCN: 0 >> >> Attributes: >> Type: $STANDARD_INFORMATION (16-0) Name: N/A Resident size: 72 >> Type: $ATTRIBUTE_LIST (32-5) Name: N/A Resident size: 96 >> Type: $FILE_NAME (48-4) Name: N/A Resident size: 86 >> Type: $DATA (128-6) Name: N/A Non-Resident size: 1024 init_size: >> 1024 >> 847844 0 0 0 0 0 0 0 >> 0 0 0 0 0 0 0 0 >> 0 0 0 0 0 0 0 0 >> 0 0 0 0 0 0 0 0 >> 0 0 0 0 0 0 0 0 >> 0 0 0 0 0 0 0 0 >> 0 0 0 0 0 0 0 0 >> 0 0 0 0 0 0 0 0 >> 0 0 0 0 0 0 0 0 >> 0 0 0 0 0 0 0 0 >> 0 0 0 0 0 0 0 0 >> 0 0 0 0 0 0 0 0 >> 0 0 0 0 0 0 0 0 >> 0 0 0 0 0 0 0 0 >> 0 0 0 0 0 0 0 0 >> 0 0 0 0 0 0 0 0 >> 0 0 0 0 0 0 0 0 >> 0 0 0 0 0 0 0 0 >> 0 0 0 0 0 0 0 0 >> 0 0 0 0 0 0 0 0 >> 0 0 0 0 0 0 0 0 >> 0 0 0 0 0 0 0 0 >> 0 0 0 0 0 0 0 0 >> 0 0 0 0 0 0 0 0 >> 0 0 0 0 0 0 0 0 >> 0 0 0 0 0 0 0 0 >> 0 0 0 0 0 0 0 0 >> 0 0 0 0 0 0 0 0 >> 0 0 0 0 0 0 0 0 >> 0 0 0 0 0 0 0 0 >> 0 0 0 0 0 0 0 0 >> 0 0 0 0 0 0 0 0 >> 0 0 0 0 0 0 0 0 >> 0 0 0 0 0 0 0 0 >> 0 0 0 0 0 0 0 0 >> 0 0 0 0 0 0 0 0 >> 0 0 0 0 0 0 0 0 >> 0 0 0 0 0 0 0 0 >> 0 0 0 0 0 0 0 0 >> 0 0 0 0 0 0 0 0 >> 0 0 0 0 0 0 0 0 >> 0 0 0 0 0 0 0 0 >> 0 0 0 0 0 0 0 0 >> 0 0 0 0 0 0 0 0 >> 0 0 0 0 0 0 0 0 >> 0 0 0 0 0 0 0 0 >> 0 0 0 0 0 0 0 0 >> 0 0 0 0 0 0 0 0 >> 0 0 0 0 0 0 0 0 >> 0 0 0 0 0 0 0 0 >> 0 0 0 0 0 0 0 0 >> 0 0 0 0 0 0 0 0 >> 0 0 0 0 0 0 0 0 >> 0 0 0 0 0 0 0 0 >> 0 0 0 0 0 0 0 0 >> 0 0 0 0 0 0 0 0 >> 0 0 0 0 0 0 0 0 >> 0 0 0 0 0 0 0 0 >> 0 0 0 0 0 0 0 0 >> 0 0 0 0 0 0 0 0 >> 0 0 0 0 0 0 0 0 >> 0 0 0 0 0 0 0 >> >> 2017-01-31 12:56 GMT-02:00 Brian Carrier <ca...@sl...>: >> >>> Hi Luis, >>> >>> My guess is that it's a file that has preallocated a large amount of >>> space, but that has not fully used it yet. NTFS allows this. If you read >>> the file, TSK will only show you the space that is used. Reading the >>> slack, gives you the rest. >>> >>> If you run 'istat' on one of these files and send it along, we can >>> confirm. >>> >>> thanks, >>> brian >>> >>> >>> On Tue, Jan 31, 2017 at 7:04 AM, Luís Filipe Nassif <lfc...@gm... >>> > wrote: >>> >>>> Hi folks, >>>> >>>> I am upgrading to tsk-4.4 to benefit from the new support to slackfiles >>>> from java bindings. But I noticed some slackfiles larger than the cluster >>>> size (4k) are created in database. Some of them have megabytes of size and >>>> its contents are accessible. Is it expected to have slackfiles larger than >>>> cluster size? Could someone explain? >>>> >>>> Thanks, >>>> Luis Nassif >>>> >>>> ------------------------------------------------------------ >>>> ------------------ >>>> Check out the vibrant tech community on one of the world's most >>>> engaging tech sites, SlashDot.org! http://sdm.link/slashdot >>>> _______________________________________________ >>>> sleuthkit-users mailing list >>>> https://lists.sourceforge.net/lists/listinfo/sleuthkit-users >>>> http://www.sleuthkit.org >>>> >>>> >>> >> > |
|
From: Luís F. N. <lfc...@gm...> - 2017-02-01 00:26:34
|
Thank you, Brian, for your explanation! No problem for our application, just curious to know if it was a bug or, if not, why it is there. But, currently, no slack files are created for VSC files and other files with initsize smaller than allocated size. I thought slack is created only when allocated > logical size (based on line 1001 of db_sqlite.cpp) And is the allocated size 4096 from istat output? I do not know where the slack size of 2.026.496 bytes came from... 2017-01-31 18:05 GMT-02:00 Brian Carrier <ca...@sl...>: > Actually, making this decision could incur some significant overhead for a > step that (at least in Autopsy) we try to keep as fast as possible. Is > your application impacted by the fact that there is a large and empty slack > file or were you just curious if it was a bug? > > > > On Tue, Jan 31, 2017 at 2:54 PM, Brian Carrier <ca...@sl...> > wrote: > >> Yea, this looks like "VDL Slack". Same general idea as in Issue 466 ( >> https://github.com/sleuthkit/sleuthkit/issues/466), but in this case the >> file has 1K of initialized size. >> >> I suppose this "slack" file is a bit wasted though because no blocks were >> allocated to it. So, there will be no real content for it. >> >> I'll make an internal story to keep track of this and maybe Ann will be >> able to take a look at not making these if they are going to be all for >> address 0. >> >> >> >> On Tue, Jan 31, 2017 at 10:55 AM, Luís Filipe Nassif <lfc...@gm... >> > wrote: >> >>> Hi Brian, >>> >>> Thank you very much for your attention. The output of >>> FsContent.getMetaDataText() (equals to istat right?) is below. The >>> system.LOG-slack size is 2.026.496 bytes and system.LOG size is 1024 bytes. >>> >>> details of /img_PC-HP.dd/vol_vol2/WINDOWS/system32/config/system.LOG-sl >>> ack >>> >>> MFT Entry Header Values: >>> Entry: 4106 Sequence: 1 >>> $LogFile Sequence Number: 79246281526 >>> Allocated File >>> Links: 1 >>> >>> $STANDARD_INFORMATION Attribute Values: >>> Flags: Hidden, Archive >>> Owner ID: 0 >>> Security ID: 281 (S-1-5-32-544) >>> Last User Journal Update Sequence Number: 105272096 >>> Created: 2004-09-02 08:00:12.000000000 (Hora oficial do Brasil) >>> File Modified: 2011-09-16 14:33:38.375000000 (Hora oficial do Brasil) >>> MFT Modified: 2011-09-16 14:33:38.375000000 (Hora oficial do Brasil) >>> Accessed: 2011-09-16 14:33:38.187500000 (Hora oficial do Brasil) >>> >>> $FILE_NAME Attribute Values: >>> Flags: Hidden, Archive >>> Name: system.LOG >>> Parent MFT Entry: 3982 Sequence: 2 >>> Allocated Size: 4096 Actual Size: 1024 >>> Created: 2004-09-02 08:00:12.000000000 (Hora oficial do Brasil) >>> File Modified: 2004-09-02 08:00:12.000000000 (Hora oficial do Brasil) >>> MFT Modified: 2004-09-02 08:00:12.000000000 (Hora oficial do Brasil) >>> Accessed: 2004-09-02 08:00:12.000000000 (Hora oficial do Brasil) >>> >>> $ATTRIBUTE_LIST Attribute Values: >>> Type: 16-0 MFT Entry: 4106 VCN: 0 >>> Type: 48-4 MFT Entry: 4106 VCN: 0 >>> Type: 128-0 MFT Entry: 40678 VCN: 0 >>> >>> Attributes: >>> Type: $STANDARD_INFORMATION (16-0) Name: N/A Resident size: 72 >>> Type: $ATTRIBUTE_LIST (32-5) Name: N/A Resident size: 96 >>> Type: $FILE_NAME (48-4) Name: N/A Resident size: 86 >>> Type: $DATA (128-6) Name: N/A Non-Resident size: 1024 init_size: >>> 1024 >>> 847844 0 0 0 0 0 0 0 >>> 0 0 0 0 0 0 0 0 >>> 0 0 0 0 0 0 0 0 >>> 0 0 0 0 0 0 0 0 >>> 0 0 0 0 0 0 0 0 >>> 0 0 0 0 0 0 0 0 >>> 0 0 0 0 0 0 0 0 >>> 0 0 0 0 0 0 0 0 >>> 0 0 0 0 0 0 0 0 >>> 0 0 0 0 0 0 0 0 >>> 0 0 0 0 0 0 0 0 >>> 0 0 0 0 0 0 0 0 >>> 0 0 0 0 0 0 0 0 >>> 0 0 0 0 0 0 0 0 >>> 0 0 0 0 0 0 0 0 >>> 0 0 0 0 0 0 0 0 >>> 0 0 0 0 0 0 0 0 >>> 0 0 0 0 0 0 0 0 >>> 0 0 0 0 0 0 0 0 >>> 0 0 0 0 0 0 0 0 >>> 0 0 0 0 0 0 0 0 >>> 0 0 0 0 0 0 0 0 >>> 0 0 0 0 0 0 0 0 >>> 0 0 0 0 0 0 0 0 >>> 0 0 0 0 0 0 0 0 >>> 0 0 0 0 0 0 0 0 >>> 0 0 0 0 0 0 0 0 >>> 0 0 0 0 0 0 0 0 >>> 0 0 0 0 0 0 0 0 >>> 0 0 0 0 0 0 0 0 >>> 0 0 0 0 0 0 0 0 >>> 0 0 0 0 0 0 0 0 >>> 0 0 0 0 0 0 0 0 >>> 0 0 0 0 0 0 0 0 >>> 0 0 0 0 0 0 0 0 >>> 0 0 0 0 0 0 0 0 >>> 0 0 0 0 0 0 0 0 >>> 0 0 0 0 0 0 0 0 >>> 0 0 0 0 0 0 0 0 >>> 0 0 0 0 0 0 0 0 >>> 0 0 0 0 0 0 0 0 >>> 0 0 0 0 0 0 0 0 >>> 0 0 0 0 0 0 0 0 >>> 0 0 0 0 0 0 0 0 >>> 0 0 0 0 0 0 0 0 >>> 0 0 0 0 0 0 0 0 >>> 0 0 0 0 0 0 0 0 >>> 0 0 0 0 0 0 0 0 >>> 0 0 0 0 0 0 0 0 >>> 0 0 0 0 0 0 0 0 >>> 0 0 0 0 0 0 0 0 >>> 0 0 0 0 0 0 0 0 >>> 0 0 0 0 0 0 0 0 >>> 0 0 0 0 0 0 0 0 >>> 0 0 0 0 0 0 0 0 >>> 0 0 0 0 0 0 0 0 >>> 0 0 0 0 0 0 0 0 >>> 0 0 0 0 0 0 0 0 >>> 0 0 0 0 0 0 0 0 >>> 0 0 0 0 0 0 0 0 >>> 0 0 0 0 0 0 0 0 >>> 0 0 0 0 0 0 0 >>> >>> 2017-01-31 12:56 GMT-02:00 Brian Carrier <ca...@sl...>: >>> >>>> Hi Luis, >>>> >>>> My guess is that it's a file that has preallocated a large amount of >>>> space, but that has not fully used it yet. NTFS allows this. If you read >>>> the file, TSK will only show you the space that is used. Reading the >>>> slack, gives you the rest. >>>> >>>> If you run 'istat' on one of these files and send it along, we can >>>> confirm. >>>> >>>> thanks, >>>> brian >>>> >>>> >>>> On Tue, Jan 31, 2017 at 7:04 AM, Luís Filipe Nassif < >>>> lfc...@gm...> wrote: >>>> >>>>> Hi folks, >>>>> >>>>> I am upgrading to tsk-4.4 to benefit from the new support to >>>>> slackfiles from java bindings. But I noticed some slackfiles larger than >>>>> the cluster size (4k) are created in database. Some of them have megabytes >>>>> of size and its contents are accessible. Is it expected to have slackfiles >>>>> larger than cluster size? Could someone explain? >>>>> >>>>> Thanks, >>>>> Luis Nassif >>>>> >>>>> ------------------------------------------------------------ >>>>> ------------------ >>>>> Check out the vibrant tech community on one of the world's most >>>>> engaging tech sites, SlashDot.org! http://sdm.link/slashdot >>>>> _______________________________________________ >>>>> sleuthkit-users mailing list >>>>> https://lists.sourceforge.net/lists/listinfo/sleuthkit-users >>>>> http://www.sleuthkit.org >>>>> >>>>> >>>> >>> >> > |
|
From: Brian C. <ca...@sl...> - 2017-02-01 16:38:29
|
Ughh. I need to better start documenting these scenarios because I always get confused by them too. I think you've found an issue and I created #756 ( https://github.com/sleuthkit/sleuthkit/issues/756) to address this. The summary of your specific questions are: - VSC is strange because WIndows seems to treat it differently and lies about initsize. It has initsize of 0, but a file size that is equal to the allocsize. - In the log file case, 4096 has been initialized, but the allocated size of the file is 2MB. On Tue, Jan 31, 2017 at 7:26 PM, Luís Filipe Nassif <lfc...@gm...> wrote: > Thank you, Brian, for your explanation! No problem for our application, > just curious to know if it was a bug or, if not, why it is there. > > But, currently, no slack files are created for VSC files and other files > with initsize smaller than allocated size. I thought slack is created only > when allocated > logical size (based on line 1001 of db_sqlite.cpp) > > And is the allocated size 4096 from istat output? I do not know where the > slack size of 2.026.496 bytes came from... > > 2017-01-31 18:05 GMT-02:00 Brian Carrier <ca...@sl...>: > >> Actually, making this decision could incur some significant overhead for >> a step that (at least in Autopsy) we try to keep as fast as possible. Is >> your application impacted by the fact that there is a large and empty slack >> file or were you just curious if it was a bug? >> >> >> >> On Tue, Jan 31, 2017 at 2:54 PM, Brian Carrier <ca...@sl...> >> wrote: >> >>> Yea, this looks like "VDL Slack". Same general idea as in Issue 466 ( >>> https://github.com/sleuthkit/sleuthkit/issues/466), but in this case >>> the file has 1K of initialized size. >>> >>> I suppose this "slack" file is a bit wasted though because no blocks >>> were allocated to it. So, there will be no real content for it. >>> >>> I'll make an internal story to keep track of this and maybe Ann will be >>> able to take a look at not making these if they are going to be all for >>> address 0. >>> >>> >>> >>> On Tue, Jan 31, 2017 at 10:55 AM, Luís Filipe Nassif < >>> lfc...@gm...> wrote: >>> >>>> Hi Brian, >>>> >>>> Thank you very much for your attention. The output of >>>> FsContent.getMetaDataText() (equals to istat right?) is below. The >>>> system.LOG-slack size is 2.026.496 bytes and system.LOG size is 1024 bytes. >>>> >>>> details of /img_PC-HP.dd/vol_vol2/WINDOWS/system32/config/system.LOG-sl >>>> ack >>>> >>>> MFT Entry Header Values: >>>> Entry: 4106 Sequence: 1 >>>> $LogFile Sequence Number: 79246281526 >>>> Allocated File >>>> Links: 1 >>>> >>>> $STANDARD_INFORMATION Attribute Values: >>>> Flags: Hidden, Archive >>>> Owner ID: 0 >>>> Security ID: 281 (S-1-5-32-544) >>>> Last User Journal Update Sequence Number: 105272096 >>>> Created: 2004-09-02 08:00:12.000000000 (Hora oficial do Brasil) >>>> File Modified: 2011-09-16 14:33:38.375000000 (Hora oficial do Brasil) >>>> MFT Modified: 2011-09-16 14:33:38.375000000 (Hora oficial do Brasil) >>>> Accessed: 2011-09-16 14:33:38.187500000 (Hora oficial do Brasil) >>>> >>>> $FILE_NAME Attribute Values: >>>> Flags: Hidden, Archive >>>> Name: system.LOG >>>> Parent MFT Entry: 3982 Sequence: 2 >>>> Allocated Size: 4096 Actual Size: 1024 >>>> Created: 2004-09-02 08:00:12.000000000 (Hora oficial do Brasil) >>>> File Modified: 2004-09-02 08:00:12.000000000 (Hora oficial do Brasil) >>>> MFT Modified: 2004-09-02 08:00:12.000000000 (Hora oficial do Brasil) >>>> Accessed: 2004-09-02 08:00:12.000000000 (Hora oficial do Brasil) >>>> >>>> $ATTRIBUTE_LIST Attribute Values: >>>> Type: 16-0 MFT Entry: 4106 VCN: 0 >>>> Type: 48-4 MFT Entry: 4106 VCN: 0 >>>> Type: 128-0 MFT Entry: 40678 VCN: 0 >>>> >>>> Attributes: >>>> Type: $STANDARD_INFORMATION (16-0) Name: N/A Resident size: 72 >>>> Type: $ATTRIBUTE_LIST (32-5) Name: N/A Resident size: 96 >>>> Type: $FILE_NAME (48-4) Name: N/A Resident size: 86 >>>> Type: $DATA (128-6) Name: N/A Non-Resident size: 1024 init_size: >>>> 1024 >>>> 847844 0 0 0 0 0 0 0 >>>> 0 0 0 0 0 0 0 0 >>>> 0 0 0 0 0 0 0 0 >>>> 0 0 0 0 0 0 0 0 >>>> 0 0 0 0 0 0 0 0 >>>> 0 0 0 0 0 0 0 0 >>>> 0 0 0 0 0 0 0 0 >>>> 0 0 0 0 0 0 0 0 >>>> 0 0 0 0 0 0 0 0 >>>> 0 0 0 0 0 0 0 0 >>>> 0 0 0 0 0 0 0 0 >>>> 0 0 0 0 0 0 0 0 >>>> 0 0 0 0 0 0 0 0 >>>> 0 0 0 0 0 0 0 0 >>>> 0 0 0 0 0 0 0 0 >>>> 0 0 0 0 0 0 0 0 >>>> 0 0 0 0 0 0 0 0 >>>> 0 0 0 0 0 0 0 0 >>>> 0 0 0 0 0 0 0 0 >>>> 0 0 0 0 0 0 0 0 >>>> 0 0 0 0 0 0 0 0 >>>> 0 0 0 0 0 0 0 0 >>>> 0 0 0 0 0 0 0 0 >>>> 0 0 0 0 0 0 0 0 >>>> 0 0 0 0 0 0 0 0 >>>> 0 0 0 0 0 0 0 0 >>>> 0 0 0 0 0 0 0 0 >>>> 0 0 0 0 0 0 0 0 >>>> 0 0 0 0 0 0 0 0 >>>> 0 0 0 0 0 0 0 0 >>>> 0 0 0 0 0 0 0 0 >>>> 0 0 0 0 0 0 0 0 >>>> 0 0 0 0 0 0 0 0 >>>> 0 0 0 0 0 0 0 0 >>>> 0 0 0 0 0 0 0 0 >>>> 0 0 0 0 0 0 0 0 >>>> 0 0 0 0 0 0 0 0 >>>> 0 0 0 0 0 0 0 0 >>>> 0 0 0 0 0 0 0 0 >>>> 0 0 0 0 0 0 0 0 >>>> 0 0 0 0 0 0 0 0 >>>> 0 0 0 0 0 0 0 0 >>>> 0 0 0 0 0 0 0 0 >>>> 0 0 0 0 0 0 0 0 >>>> 0 0 0 0 0 0 0 0 >>>> 0 0 0 0 0 0 0 0 >>>> 0 0 0 0 0 0 0 0 >>>> 0 0 0 0 0 0 0 0 >>>> 0 0 0 0 0 0 0 0 >>>> 0 0 0 0 0 0 0 0 >>>> 0 0 0 0 0 0 0 0 >>>> 0 0 0 0 0 0 0 0 >>>> 0 0 0 0 0 0 0 0 >>>> 0 0 0 0 0 0 0 0 >>>> 0 0 0 0 0 0 0 0 >>>> 0 0 0 0 0 0 0 0 >>>> 0 0 0 0 0 0 0 0 >>>> 0 0 0 0 0 0 0 0 >>>> 0 0 0 0 0 0 0 0 >>>> 0 0 0 0 0 0 0 0 >>>> 0 0 0 0 0 0 0 0 >>>> 0 0 0 0 0 0 0 >>>> >>>> 2017-01-31 12:56 GMT-02:00 Brian Carrier <ca...@sl...>: >>>> >>>>> Hi Luis, >>>>> >>>>> My guess is that it's a file that has preallocated a large amount of >>>>> space, but that has not fully used it yet. NTFS allows this. If you read >>>>> the file, TSK will only show you the space that is used. Reading the >>>>> slack, gives you the rest. >>>>> >>>>> If you run 'istat' on one of these files and send it along, we can >>>>> confirm. >>>>> >>>>> thanks, >>>>> brian >>>>> >>>>> >>>>> On Tue, Jan 31, 2017 at 7:04 AM, Luís Filipe Nassif < >>>>> lfc...@gm...> wrote: >>>>> >>>>>> Hi folks, >>>>>> >>>>>> I am upgrading to tsk-4.4 to benefit from the new support to >>>>>> slackfiles from java bindings. But I noticed some slackfiles larger than >>>>>> the cluster size (4k) are created in database. Some of them have megabytes >>>>>> of size and its contents are accessible. Is it expected to have slackfiles >>>>>> larger than cluster size? Could someone explain? >>>>>> >>>>>> Thanks, >>>>>> Luis Nassif >>>>>> >>>>>> ------------------------------------------------------------ >>>>>> ------------------ >>>>>> Check out the vibrant tech community on one of the world's most >>>>>> engaging tech sites, SlashDot.org! http://sdm.link/slashdot >>>>>> _______________________________________________ >>>>>> sleuthkit-users mailing list >>>>>> https://lists.sourceforge.net/lists/listinfo/sleuthkit-users >>>>>> http://www.sleuthkit.org >>>>>> >>>>>> >>>>> >>>> >>> >> > |
|
From: D R. <da...@gm...> - 2017-02-01 17:05:32
|
Don't wish to interrupt but, I find those that use TSK are very familiar with the tool along with knowing more under the Hood about forensics than other forums such as those for guidance tools. Not disrespecting those folks, just see those posting on this forum, being at a higher level. And thanks for showing me how much I still need to learn and how informative this group is. Just my two cents. Dean On Wed, Feb 1, 2017, 09:43 Brian Carrier <ca...@sl...> wrote: > Ughh. I need to better start documenting these scenarios because I always > get confused by them too. > > I think you've found an issue and I created #756 ( > https://github.com/sleuthkit/sleuthkit/issues/756) to address this. > > The summary of your specific questions are: > - VSC is strange because WIndows seems to treat it differently and lies > about initsize. It has initsize of 0, but a file size that is equal to the > allocsize. > - In the log file case, 4096 has been initialized, but the allocated size > of the file is 2MB. > > > > > > > > > On Tue, Jan 31, 2017 at 7:26 PM, Luís Filipe Nassif <lfc...@gm...> > wrote: > > Thank you, Brian, for your explanation! No problem for our application, > just curious to know if it was a bug or, if not, why it is there. > > But, currently, no slack files are created for VSC files and other files > with initsize smaller than allocated size. I thought slack is created only > when allocated > logical size (based on line 1001 of db_sqlite.cpp) > > And is the allocated size 4096 from istat output? I do not know where the > slack size of 2.026.496 bytes came from... > > 2017-01-31 18:05 GMT-02:00 Brian Carrier <ca...@sl...>: > > Actually, making this decision could incur some significant overhead for a > step that (at least in Autopsy) we try to keep as fast as possible. Is > your application impacted by the fact that there is a large and empty slack > file or were you just curious if it was a bug? > > > > On Tue, Jan 31, 2017 at 2:54 PM, Brian Carrier <ca...@sl...> > wrote: > > Yea, this looks like "VDL Slack". Same general idea as in Issue 466 ( > https://github.com/sleuthkit/sleuthkit/issues/466), but in this case the > file has 1K of initialized size. > > I suppose this "slack" file is a bit wasted though because no blocks were > allocated to it. So, there will be no real content for it. > > I'll make an internal story to keep track of this and maybe Ann will be > able to take a look at not making these if they are going to be all for > address 0. > > > > On Tue, Jan 31, 2017 at 10:55 AM, Luís Filipe Nassif <lfc...@gm...> > wrote: > > Hi Brian, > > Thank you very much for your attention. The output of > FsContent.getMetaDataText() (equals to istat right?) is below. The > system.LOG-slack size is 2.026.496 bytes and system.LOG size is 1024 bytes. > > details of /img_PC-HP.dd/vol_vol2/WINDOWS/system32/config/system.LOG-slack > > MFT Entry Header Values: > Entry: 4106 Sequence: 1 > $LogFile Sequence Number: 79246281526 > Allocated File > Links: 1 > > $STANDARD_INFORMATION Attribute Values: > Flags: Hidden, Archive > Owner ID: 0 > Security ID: 281 (S-1-5-32-544) > Last User Journal Update Sequence Number: 105272096 > Created: 2004-09-02 08:00:12.000000000 (Hora oficial do Brasil) > File Modified: 2011-09-16 14:33:38.375000000 (Hora oficial do Brasil) > MFT Modified: 2011-09-16 14:33:38.375000000 (Hora oficial do Brasil) > Accessed: 2011-09-16 14:33:38.187500000 (Hora oficial do Brasil) > > $FILE_NAME Attribute Values: > Flags: Hidden, Archive > Name: system.LOG > Parent MFT Entry: 3982 Sequence: 2 > Allocated Size: 4096 Actual Size: 1024 > Created: 2004-09-02 08:00:12.000000000 (Hora oficial do Brasil) > File Modified: 2004-09-02 08:00:12.000000000 (Hora oficial do Brasil) > MFT Modified: 2004-09-02 08:00:12.000000000 (Hora oficial do Brasil) > Accessed: 2004-09-02 08:00:12.000000000 (Hora oficial do Brasil) > > $ATTRIBUTE_LIST Attribute Values: > Type: 16-0 MFT Entry: 4106 VCN: 0 > Type: 48-4 MFT Entry: 4106 VCN: 0 > Type: 128-0 MFT Entry: 40678 VCN: 0 > > Attributes: > Type: $STANDARD_INFORMATION (16-0) Name: N/A Resident size: 72 > Type: $ATTRIBUTE_LIST (32-5) Name: N/A Resident size: 96 > Type: $FILE_NAME (48-4) Name: N/A Resident size: 86 > Type: $DATA (128-6) Name: N/A Non-Resident size: 1024 init_size: > 1024 > 847844 0 0 0 0 0 0 0 > 0 0 0 0 0 0 0 0 > 0 0 0 0 0 0 0 0 > 0 0 0 0 0 0 0 0 > 0 0 0 0 0 0 0 0 > 0 0 0 0 0 0 0 0 > 0 0 0 0 0 0 0 0 > 0 0 0 0 0 0 0 0 > 0 0 0 0 0 0 0 0 > 0 0 0 0 0 0 0 0 > 0 0 0 0 0 0 0 0 > 0 0 0 0 0 0 0 0 > 0 0 0 0 0 0 0 0 > 0 0 0 0 0 0 0 0 > 0 0 0 0 0 0 0 0 > 0 0 0 0 0 0 0 0 > 0 0 0 0 0 0 0 0 > 0 0 0 0 0 0 0 0 > 0 0 0 0 0 0 0 0 > 0 0 0 0 0 0 0 0 > 0 0 0 0 0 0 0 0 > 0 0 0 0 0 0 0 0 > 0 0 0 0 0 0 0 0 > 0 0 0 0 0 0 0 0 > 0 0 0 0 0 0 0 0 > 0 0 0 0 0 0 0 0 > 0 0 0 0 0 0 0 0 > 0 0 0 0 0 0 0 0 > 0 0 0 0 0 0 0 0 > 0 0 0 0 0 0 0 0 > 0 0 0 0 0 0 0 0 > 0 0 0 0 0 0 0 0 > 0 0 0 0 0 0 0 0 > 0 0 0 0 0 0 0 0 > 0 0 0 0 0 0 0 0 > 0 0 0 0 0 0 0 0 > 0 0 0 0 0 0 0 0 > 0 0 0 0 0 0 0 0 > 0 0 0 0 0 0 0 0 > 0 0 0 0 0 0 0 0 > 0 0 0 0 0 0 0 0 > 0 0 0 0 0 0 0 0 > 0 0 0 0 0 0 0 0 > 0 0 0 0 0 0 0 0 > 0 0 0 0 0 0 0 0 > 0 0 0 0 0 0 0 0 > 0 0 0 0 0 0 0 0 > 0 0 0 0 0 0 0 0 > 0 0 0 0 0 0 0 0 > 0 0 0 0 0 0 0 0 > 0 0 0 0 0 0 0 0 > 0 0 0 0 0 0 0 0 > 0 0 0 0 0 0 0 0 > 0 0 0 0 0 0 0 0 > 0 0 0 0 0 0 0 0 > 0 0 0 0 0 0 0 0 > 0 0 0 0 0 0 0 0 > 0 0 0 0 0 0 0 0 > 0 0 0 0 0 0 0 0 > 0 0 0 0 0 0 0 0 > 0 0 0 0 0 0 0 0 > 0 0 0 0 0 0 0 > > 2017-01-31 12:56 GMT-02:00 Brian Carrier <ca...@sl...>: > > Hi Luis, > > My guess is that it's a file that has preallocated a large amount of > space, but that has not fully used it yet. NTFS allows this. If you read > the file, TSK will only show you the space that is used. Reading the > slack, gives you the rest. > > If you run 'istat' on one of these files and send it along, we can confirm. > > thanks, > brian > > > On Tue, Jan 31, 2017 at 7:04 AM, Luís Filipe Nassif <lfc...@gm...> > wrote: > > Hi folks, > > I am upgrading to tsk-4.4 to benefit from the new support to slackfiles > from java bindings. But I noticed some slackfiles larger than the cluster > size (4k) are created in database. Some of them have megabytes of size and > its contents are accessible. Is it expected to have slackfiles larger than > cluster size? Could someone explain? > > Thanks, > Luis Nassif > > > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, SlashDot.org! http://sdm.link/slashdot > _______________________________________________ > sleuthkit-users mailing list > https://lists.sourceforge.net/lists/listinfo/sleuthkit-users > http://www.sleuthkit.org > > > > > > > > > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, SlashDot.org! http://sdm.link/slashdot > _______________________________________________ > sleuthkit-users mailing list > https://lists.sourceforge.net/lists/listinfo/sleuthkit-users > http://www.sleuthkit.org > |
|
From: Brian C. <ca...@sl...> - 2017-02-01 17:12:43
|
This fix is now in the develop-4.4 branch. We'll merge it into develop after we do a few other minor things on this branch. On Wed, Feb 1, 2017 at 11:38 AM, Brian Carrier <ca...@sl...> wrote: > Ughh. I need to better start documenting these scenarios because I always > get confused by them too. > > I think you've found an issue and I created #756 ( > https://github.com/sleuthkit/sleuthkit/issues/756) to address this. > > The summary of your specific questions are: > - VSC is strange because WIndows seems to treat it differently and lies > about initsize. It has initsize of 0, but a file size that is equal to the > allocsize. > - In the log file case, 4096 has been initialized, but the allocated size > of the file is 2MB. > > > > > > > > > On Tue, Jan 31, 2017 at 7:26 PM, Luís Filipe Nassif <lfc...@gm...> > wrote: > >> Thank you, Brian, for your explanation! No problem for our application, >> just curious to know if it was a bug or, if not, why it is there. >> >> But, currently, no slack files are created for VSC files and other files >> with initsize smaller than allocated size. I thought slack is created only >> when allocated > logical size (based on line 1001 of db_sqlite.cpp) >> >> And is the allocated size 4096 from istat output? I do not know where the >> slack size of 2.026.496 bytes came from... >> >> 2017-01-31 18:05 GMT-02:00 Brian Carrier <ca...@sl...>: >> >>> Actually, making this decision could incur some significant overhead for >>> a step that (at least in Autopsy) we try to keep as fast as possible. Is >>> your application impacted by the fact that there is a large and empty slack >>> file or were you just curious if it was a bug? >>> >>> >>> >>> On Tue, Jan 31, 2017 at 2:54 PM, Brian Carrier <ca...@sl...> >>> wrote: >>> >>>> Yea, this looks like "VDL Slack". Same general idea as in Issue 466 ( >>>> https://github.com/sleuthkit/sleuthkit/issues/466), but in this case >>>> the file has 1K of initialized size. >>>> >>>> I suppose this "slack" file is a bit wasted though because no blocks >>>> were allocated to it. So, there will be no real content for it. >>>> >>>> I'll make an internal story to keep track of this and maybe Ann will be >>>> able to take a look at not making these if they are going to be all for >>>> address 0. >>>> >>>> >>>> >>>> On Tue, Jan 31, 2017 at 10:55 AM, Luís Filipe Nassif < >>>> lfc...@gm...> wrote: >>>> >>>>> Hi Brian, >>>>> >>>>> Thank you very much for your attention. The output of >>>>> FsContent.getMetaDataText() (equals to istat right?) is below. The >>>>> system.LOG-slack size is 2.026.496 bytes and system.LOG size is 1024 bytes. >>>>> >>>>> details of /img_PC-HP.dd/vol_vol2/WINDOWS >>>>> /system32/config/system.LOG-slack >>>>> >>>>> MFT Entry Header Values: >>>>> Entry: 4106 Sequence: 1 >>>>> $LogFile Sequence Number: 79246281526 >>>>> Allocated File >>>>> Links: 1 >>>>> >>>>> $STANDARD_INFORMATION Attribute Values: >>>>> Flags: Hidden, Archive >>>>> Owner ID: 0 >>>>> Security ID: 281 (S-1-5-32-544) >>>>> Last User Journal Update Sequence Number: 105272096 >>>>> Created: 2004-09-02 08:00:12.000000000 (Hora oficial do Brasil) >>>>> File Modified: 2011-09-16 14:33:38.375000000 (Hora oficial do Brasil) >>>>> MFT Modified: 2011-09-16 14:33:38.375000000 (Hora oficial do Brasil) >>>>> Accessed: 2011-09-16 14:33:38.187500000 (Hora oficial do Brasil) >>>>> >>>>> $FILE_NAME Attribute Values: >>>>> Flags: Hidden, Archive >>>>> Name: system.LOG >>>>> Parent MFT Entry: 3982 Sequence: 2 >>>>> Allocated Size: 4096 Actual Size: 1024 >>>>> Created: 2004-09-02 08:00:12.000000000 (Hora oficial do Brasil) >>>>> File Modified: 2004-09-02 08:00:12.000000000 (Hora oficial do Brasil) >>>>> MFT Modified: 2004-09-02 08:00:12.000000000 (Hora oficial do Brasil) >>>>> Accessed: 2004-09-02 08:00:12.000000000 (Hora oficial do Brasil) >>>>> >>>>> $ATTRIBUTE_LIST Attribute Values: >>>>> Type: 16-0 MFT Entry: 4106 VCN: 0 >>>>> Type: 48-4 MFT Entry: 4106 VCN: 0 >>>>> Type: 128-0 MFT Entry: 40678 VCN: 0 >>>>> >>>>> Attributes: >>>>> Type: $STANDARD_INFORMATION (16-0) Name: N/A Resident size: 72 >>>>> Type: $ATTRIBUTE_LIST (32-5) Name: N/A Resident size: 96 >>>>> Type: $FILE_NAME (48-4) Name: N/A Resident size: 86 >>>>> Type: $DATA (128-6) Name: N/A Non-Resident size: 1024 >>>>> init_size: 1024 >>>>> 847844 0 0 0 0 0 0 0 >>>>> 0 0 0 0 0 0 0 0 >>>>> 0 0 0 0 0 0 0 0 >>>>> 0 0 0 0 0 0 0 0 >>>>> 0 0 0 0 0 0 0 0 >>>>> 0 0 0 0 0 0 0 0 >>>>> 0 0 0 0 0 0 0 0 >>>>> 0 0 0 0 0 0 0 0 >>>>> 0 0 0 0 0 0 0 0 >>>>> 0 0 0 0 0 0 0 0 >>>>> 0 0 0 0 0 0 0 0 >>>>> 0 0 0 0 0 0 0 0 >>>>> 0 0 0 0 0 0 0 0 >>>>> 0 0 0 0 0 0 0 0 >>>>> 0 0 0 0 0 0 0 0 >>>>> 0 0 0 0 0 0 0 0 >>>>> 0 0 0 0 0 0 0 0 >>>>> 0 0 0 0 0 0 0 0 >>>>> 0 0 0 0 0 0 0 0 >>>>> 0 0 0 0 0 0 0 0 >>>>> 0 0 0 0 0 0 0 0 >>>>> 0 0 0 0 0 0 0 0 >>>>> 0 0 0 0 0 0 0 0 >>>>> 0 0 0 0 0 0 0 0 >>>>> 0 0 0 0 0 0 0 0 >>>>> 0 0 0 0 0 0 0 0 >>>>> 0 0 0 0 0 0 0 0 >>>>> 0 0 0 0 0 0 0 0 >>>>> 0 0 0 0 0 0 0 0 >>>>> 0 0 0 0 0 0 0 0 >>>>> 0 0 0 0 0 0 0 0 >>>>> 0 0 0 0 0 0 0 0 >>>>> 0 0 0 0 0 0 0 0 >>>>> 0 0 0 0 0 0 0 0 >>>>> 0 0 0 0 0 0 0 0 >>>>> 0 0 0 0 0 0 0 0 >>>>> 0 0 0 0 0 0 0 0 >>>>> 0 0 0 0 0 0 0 0 >>>>> 0 0 0 0 0 0 0 0 >>>>> 0 0 0 0 0 0 0 0 >>>>> 0 0 0 0 0 0 0 0 >>>>> 0 0 0 0 0 0 0 0 >>>>> 0 0 0 0 0 0 0 0 >>>>> 0 0 0 0 0 0 0 0 >>>>> 0 0 0 0 0 0 0 0 >>>>> 0 0 0 0 0 0 0 0 >>>>> 0 0 0 0 0 0 0 0 >>>>> 0 0 0 0 0 0 0 0 >>>>> 0 0 0 0 0 0 0 0 >>>>> 0 0 0 0 0 0 0 0 >>>>> 0 0 0 0 0 0 0 0 >>>>> 0 0 0 0 0 0 0 0 >>>>> 0 0 0 0 0 0 0 0 >>>>> 0 0 0 0 0 0 0 0 >>>>> 0 0 0 0 0 0 0 0 >>>>> 0 0 0 0 0 0 0 0 >>>>> 0 0 0 0 0 0 0 0 >>>>> 0 0 0 0 0 0 0 0 >>>>> 0 0 0 0 0 0 0 0 >>>>> 0 0 0 0 0 0 0 0 >>>>> 0 0 0 0 0 0 0 0 >>>>> 0 0 0 0 0 0 0 >>>>> >>>>> 2017-01-31 12:56 GMT-02:00 Brian Carrier <ca...@sl...>: >>>>> >>>>>> Hi Luis, >>>>>> >>>>>> My guess is that it's a file that has preallocated a large amount of >>>>>> space, but that has not fully used it yet. NTFS allows this. If you read >>>>>> the file, TSK will only show you the space that is used. Reading the >>>>>> slack, gives you the rest. >>>>>> >>>>>> If you run 'istat' on one of these files and send it along, we can >>>>>> confirm. >>>>>> >>>>>> thanks, >>>>>> brian >>>>>> >>>>>> >>>>>> On Tue, Jan 31, 2017 at 7:04 AM, Luís Filipe Nassif < >>>>>> lfc...@gm...> wrote: >>>>>> >>>>>>> Hi folks, >>>>>>> >>>>>>> I am upgrading to tsk-4.4 to benefit from the new support to >>>>>>> slackfiles from java bindings. But I noticed some slackfiles larger than >>>>>>> the cluster size (4k) are created in database. Some of them have megabytes >>>>>>> of size and its contents are accessible. Is it expected to have slackfiles >>>>>>> larger than cluster size? Could someone explain? >>>>>>> >>>>>>> Thanks, >>>>>>> Luis Nassif >>>>>>> >>>>>>> ------------------------------------------------------------ >>>>>>> ------------------ >>>>>>> Check out the vibrant tech community on one of the world's most >>>>>>> engaging tech sites, SlashDot.org! http://sdm.link/slashdot >>>>>>> _______________________________________________ >>>>>>> sleuthkit-users mailing list >>>>>>> https://lists.sourceforge.net/lists/listinfo/sleuthkit-users >>>>>>> http://www.sleuthkit.org >>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> > |
|
From: Luís F. N. <lfc...@gm...> - 2017-02-01 17:30:59
|
Thank you, Brian, for the change! I think VSC file content will be accessible now! And to clarify, I was a bit confused about the slack size of 2.026.496 bytes, because the allocated size of the system.LOG file was not shown in istat output. But I confirmed with another tool that the allocated size of system.LOG is 2.027.520 bytes and with only 1024 bytes of logical size that give us 2.026.496 bytes for the slack size. So everything was ok! Thanks again! Luis 2017-02-01 15:06 GMT-02:00 Brian Carrier <ca...@sl...>: > This fix is now in the develop-4.4 branch. We'll merge it into develop > after we do a few other minor things on this branch. > > > On Wed, Feb 1, 2017 at 11:38 AM, Brian Carrier <ca...@sl...> > wrote: > >> Ughh. I need to better start documenting these scenarios because I >> always get confused by them too. >> >> I think you've found an issue and I created #756 ( >> https://github.com/sleuthkit/sleuthkit/issues/756) to address this. >> >> The summary of your specific questions are: >> - VSC is strange because WIndows seems to treat it differently and lies >> about initsize. It has initsize of 0, but a file size that is equal to the >> allocsize. >> - In the log file case, 4096 has been initialized, but the allocated size >> of the file is 2MB. >> >> >> >> >> >> >> >> >> On Tue, Jan 31, 2017 at 7:26 PM, Luís Filipe Nassif <lfc...@gm...> >> wrote: >> >>> Thank you, Brian, for your explanation! No problem for our application, >>> just curious to know if it was a bug or, if not, why it is there. >>> >>> But, currently, no slack files are created for VSC files and other files >>> with initsize smaller than allocated size. I thought slack is created only >>> when allocated > logical size (based on line 1001 of db_sqlite.cpp) >>> >>> And is the allocated size 4096 from istat output? I do not know where >>> the slack size of 2.026.496 bytes came from... >>> >>> 2017-01-31 18:05 GMT-02:00 Brian Carrier <ca...@sl...>: >>> >>>> Actually, making this decision could incur some significant overhead >>>> for a step that (at least in Autopsy) we try to keep as fast as possible. >>>> Is your application impacted by the fact that there is a large and empty >>>> slack file or were you just curious if it was a bug? >>>> >>>> >>>> >>>> On Tue, Jan 31, 2017 at 2:54 PM, Brian Carrier <ca...@sl...> >>>> wrote: >>>> >>>>> Yea, this looks like "VDL Slack". Same general idea as in Issue 466 ( >>>>> https://github.com/sleuthkit/sleuthkit/issues/466), but in this case >>>>> the file has 1K of initialized size. >>>>> >>>>> I suppose this "slack" file is a bit wasted though because no blocks >>>>> were allocated to it. So, there will be no real content for it. >>>>> >>>>> I'll make an internal story to keep track of this and maybe Ann will >>>>> be able to take a look at not making these if they are going to be all for >>>>> address 0. >>>>> >>>>> >>>>> >>>>> On Tue, Jan 31, 2017 at 10:55 AM, Luís Filipe Nassif < >>>>> lfc...@gm...> wrote: >>>>> >>>>>> Hi Brian, >>>>>> >>>>>> Thank you very much for your attention. The output of >>>>>> FsContent.getMetaDataText() (equals to istat right?) is below. The >>>>>> system.LOG-slack size is 2.026.496 bytes and system.LOG size is 1024 bytes. >>>>>> >>>>>> details of /img_PC-HP.dd/vol_vol2/WINDOWS >>>>>> /system32/config/system.LOG-slack >>>>>> >>>>>> MFT Entry Header Values: >>>>>> Entry: 4106 Sequence: 1 >>>>>> $LogFile Sequence Number: 79246281526 >>>>>> Allocated File >>>>>> Links: 1 >>>>>> >>>>>> $STANDARD_INFORMATION Attribute Values: >>>>>> Flags: Hidden, Archive >>>>>> Owner ID: 0 >>>>>> Security ID: 281 (S-1-5-32-544) >>>>>> Last User Journal Update Sequence Number: 105272096 >>>>>> Created: 2004-09-02 08:00:12.000000000 (Hora oficial do Brasil) >>>>>> File Modified: 2011-09-16 14:33:38.375000000 (Hora oficial do Brasil) >>>>>> MFT Modified: 2011-09-16 14:33:38.375000000 (Hora oficial do Brasil) >>>>>> Accessed: 2011-09-16 14:33:38.187500000 (Hora oficial do Brasil) >>>>>> >>>>>> $FILE_NAME Attribute Values: >>>>>> Flags: Hidden, Archive >>>>>> Name: system.LOG >>>>>> Parent MFT Entry: 3982 Sequence: 2 >>>>>> Allocated Size: 4096 Actual Size: 1024 >>>>>> Created: 2004-09-02 08:00:12.000000000 (Hora oficial do Brasil) >>>>>> File Modified: 2004-09-02 08:00:12.000000000 (Hora oficial do Brasil) >>>>>> MFT Modified: 2004-09-02 08:00:12.000000000 (Hora oficial do Brasil) >>>>>> Accessed: 2004-09-02 08:00:12.000000000 (Hora oficial do Brasil) >>>>>> >>>>>> $ATTRIBUTE_LIST Attribute Values: >>>>>> Type: 16-0 MFT Entry: 4106 VCN: 0 >>>>>> Type: 48-4 MFT Entry: 4106 VCN: 0 >>>>>> Type: 128-0 MFT Entry: 40678 VCN: 0 >>>>>> >>>>>> Attributes: >>>>>> Type: $STANDARD_INFORMATION (16-0) Name: N/A Resident size: 72 >>>>>> Type: $ATTRIBUTE_LIST (32-5) Name: N/A Resident size: 96 >>>>>> Type: $FILE_NAME (48-4) Name: N/A Resident size: 86 >>>>>> Type: $DATA (128-6) Name: N/A Non-Resident size: 1024 >>>>>> init_size: 1024 >>>>>> 847844 0 0 0 0 0 0 0 >>>>>> 0 0 0 0 0 0 0 0 >>>>>> 0 0 0 0 0 0 0 0 >>>>>> 0 0 0 0 0 0 0 0 >>>>>> 0 0 0 0 0 0 0 0 >>>>>> 0 0 0 0 0 0 0 0 >>>>>> 0 0 0 0 0 0 0 0 >>>>>> 0 0 0 0 0 0 0 0 >>>>>> 0 0 0 0 0 0 0 0 >>>>>> 0 0 0 0 0 0 0 0 >>>>>> 0 0 0 0 0 0 0 0 >>>>>> 0 0 0 0 0 0 0 0 >>>>>> 0 0 0 0 0 0 0 0 >>>>>> 0 0 0 0 0 0 0 0 >>>>>> 0 0 0 0 0 0 0 0 >>>>>> 0 0 0 0 0 0 0 0 >>>>>> 0 0 0 0 0 0 0 0 >>>>>> 0 0 0 0 0 0 0 0 >>>>>> 0 0 0 0 0 0 0 0 >>>>>> 0 0 0 0 0 0 0 0 >>>>>> 0 0 0 0 0 0 0 0 >>>>>> 0 0 0 0 0 0 0 0 >>>>>> 0 0 0 0 0 0 0 0 >>>>>> 0 0 0 0 0 0 0 0 >>>>>> 0 0 0 0 0 0 0 0 >>>>>> 0 0 0 0 0 0 0 0 >>>>>> 0 0 0 0 0 0 0 0 >>>>>> 0 0 0 0 0 0 0 0 >>>>>> 0 0 0 0 0 0 0 0 >>>>>> 0 0 0 0 0 0 0 0 >>>>>> 0 0 0 0 0 0 0 0 >>>>>> 0 0 0 0 0 0 0 0 >>>>>> 0 0 0 0 0 0 0 0 >>>>>> 0 0 0 0 0 0 0 0 >>>>>> 0 0 0 0 0 0 0 0 >>>>>> 0 0 0 0 0 0 0 0 >>>>>> 0 0 0 0 0 0 0 0 >>>>>> 0 0 0 0 0 0 0 0 >>>>>> 0 0 0 0 0 0 0 0 >>>>>> 0 0 0 0 0 0 0 0 >>>>>> 0 0 0 0 0 0 0 0 >>>>>> 0 0 0 0 0 0 0 0 >>>>>> 0 0 0 0 0 0 0 0 >>>>>> 0 0 0 0 0 0 0 0 >>>>>> 0 0 0 0 0 0 0 0 >>>>>> 0 0 0 0 0 0 0 0 >>>>>> 0 0 0 0 0 0 0 0 >>>>>> 0 0 0 0 0 0 0 0 >>>>>> 0 0 0 0 0 0 0 0 >>>>>> 0 0 0 0 0 0 0 0 >>>>>> 0 0 0 0 0 0 0 0 >>>>>> 0 0 0 0 0 0 0 0 >>>>>> 0 0 0 0 0 0 0 0 >>>>>> 0 0 0 0 0 0 0 0 >>>>>> 0 0 0 0 0 0 0 0 >>>>>> 0 0 0 0 0 0 0 0 >>>>>> 0 0 0 0 0 0 0 0 >>>>>> 0 0 0 0 0 0 0 0 >>>>>> 0 0 0 0 0 0 0 0 >>>>>> 0 0 0 0 0 0 0 0 >>>>>> 0 0 0 0 0 0 0 0 >>>>>> 0 0 0 0 0 0 0 >>>>>> >>>>>> 2017-01-31 12:56 GMT-02:00 Brian Carrier <ca...@sl...>: >>>>>> >>>>>>> Hi Luis, >>>>>>> >>>>>>> My guess is that it's a file that has preallocated a large amount of >>>>>>> space, but that has not fully used it yet. NTFS allows this. If you read >>>>>>> the file, TSK will only show you the space that is used. Reading the >>>>>>> slack, gives you the rest. >>>>>>> >>>>>>> If you run 'istat' on one of these files and send it along, we can >>>>>>> confirm. >>>>>>> >>>>>>> thanks, >>>>>>> brian >>>>>>> >>>>>>> >>>>>>> On Tue, Jan 31, 2017 at 7:04 AM, Luís Filipe Nassif < >>>>>>> lfc...@gm...> wrote: >>>>>>> >>>>>>>> Hi folks, >>>>>>>> >>>>>>>> I am upgrading to tsk-4.4 to benefit from the new support to >>>>>>>> slackfiles from java bindings. But I noticed some slackfiles larger than >>>>>>>> the cluster size (4k) are created in database. Some of them have megabytes >>>>>>>> of size and its contents are accessible. Is it expected to have slackfiles >>>>>>>> larger than cluster size? Could someone explain? >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Luis Nassif >>>>>>>> >>>>>>>> ------------------------------------------------------------ >>>>>>>> ------------------ >>>>>>>> Check out the vibrant tech community on one of the world's most >>>>>>>> engaging tech sites, SlashDot.org! http://sdm.link/slashdot >>>>>>>> _______________________________________________ >>>>>>>> sleuthkit-users mailing list >>>>>>>> https://lists.sourceforge.net/lists/listinfo/sleuthkit-users >>>>>>>> http://www.sleuthkit.org >>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> > |
|
From: Luís F. N. <lfc...@gm...> - 2017-02-01 17:47:16
|
I've just confirmed VSC content is now accessible through slack files with the patch! 2017-02-01 15:30 GMT-02:00 Luís Filipe Nassif <lfc...@gm...>: > Thank you, Brian, for the change! I think VSC file content will be > accessible now! > > And to clarify, I was a bit confused about the slack size of 2.026.496 > bytes, because the allocated size of the system.LOG file was not shown in > istat output. But I confirmed with another tool that the allocated size of > system.LOG is 2.027.520 bytes and with only 1024 bytes of logical size > that give us 2.026.496 bytes for the slack size. So everything was ok! > > Thanks again! > Luis > > 2017-02-01 15:06 GMT-02:00 Brian Carrier <ca...@sl...>: > >> This fix is now in the develop-4.4 branch. We'll merge it into develop >> after we do a few other minor things on this branch. >> >> >> On Wed, Feb 1, 2017 at 11:38 AM, Brian Carrier <ca...@sl...> >> wrote: >> >>> Ughh. I need to better start documenting these scenarios because I >>> always get confused by them too. >>> >>> I think you've found an issue and I created #756 ( >>> https://github.com/sleuthkit/sleuthkit/issues/756) to address this. >>> >>> The summary of your specific questions are: >>> - VSC is strange because WIndows seems to treat it differently and lies >>> about initsize. It has initsize of 0, but a file size that is equal to the >>> allocsize. >>> - In the log file case, 4096 has been initialized, but the allocated >>> size of the file is 2MB. >>> >>> >>> >>> >>> >>> >>> >>> >>> On Tue, Jan 31, 2017 at 7:26 PM, Luís Filipe Nassif <lfc...@gm... >>> > wrote: >>> >>>> Thank you, Brian, for your explanation! No problem for our application, >>>> just curious to know if it was a bug or, if not, why it is there. >>>> >>>> But, currently, no slack files are created for VSC files and other >>>> files with initsize smaller than allocated size. I thought slack is created >>>> only when allocated > logical size (based on line 1001 of db_sqlite.cpp) >>>> >>>> And is the allocated size 4096 from istat output? I do not know where >>>> the slack size of 2.026.496 bytes came from... >>>> >>>> 2017-01-31 18:05 GMT-02:00 Brian Carrier <ca...@sl...>: >>>> >>>>> Actually, making this decision could incur some significant overhead >>>>> for a step that (at least in Autopsy) we try to keep as fast as possible. >>>>> Is your application impacted by the fact that there is a large and empty >>>>> slack file or were you just curious if it was a bug? >>>>> >>>>> >>>>> >>>>> On Tue, Jan 31, 2017 at 2:54 PM, Brian Carrier <ca...@sl...> >>>>> wrote: >>>>> >>>>>> Yea, this looks like "VDL Slack". Same general idea as in Issue 466 ( >>>>>> https://github.com/sleuthkit/sleuthkit/issues/466), but in this case >>>>>> the file has 1K of initialized size. >>>>>> >>>>>> I suppose this "slack" file is a bit wasted though because no blocks >>>>>> were allocated to it. So, there will be no real content for it. >>>>>> >>>>>> I'll make an internal story to keep track of this and maybe Ann will >>>>>> be able to take a look at not making these if they are going to be all for >>>>>> address 0. >>>>>> >>>>>> >>>>>> >>>>>> On Tue, Jan 31, 2017 at 10:55 AM, Luís Filipe Nassif < >>>>>> lfc...@gm...> wrote: >>>>>> >>>>>>> Hi Brian, >>>>>>> >>>>>>> Thank you very much for your attention. The output of >>>>>>> FsContent.getMetaDataText() (equals to istat right?) is below. The >>>>>>> system.LOG-slack size is 2.026.496 bytes and system.LOG size is 1024 bytes. >>>>>>> >>>>>>> details of /img_PC-HP.dd/vol_vol2/WINDOWS >>>>>>> /system32/config/system.LOG-slack >>>>>>> >>>>>>> MFT Entry Header Values: >>>>>>> Entry: 4106 Sequence: 1 >>>>>>> $LogFile Sequence Number: 79246281526 >>>>>>> Allocated File >>>>>>> Links: 1 >>>>>>> >>>>>>> $STANDARD_INFORMATION Attribute Values: >>>>>>> Flags: Hidden, Archive >>>>>>> Owner ID: 0 >>>>>>> Security ID: 281 (S-1-5-32-544) >>>>>>> Last User Journal Update Sequence Number: 105272096 >>>>>>> Created: 2004-09-02 08:00:12.000000000 (Hora oficial do Brasil) >>>>>>> File Modified: 2011-09-16 14:33:38.375000000 (Hora oficial do >>>>>>> Brasil) >>>>>>> MFT Modified: 2011-09-16 14:33:38.375000000 (Hora oficial do Brasil) >>>>>>> Accessed: 2011-09-16 14:33:38.187500000 (Hora oficial do Brasil) >>>>>>> >>>>>>> $FILE_NAME Attribute Values: >>>>>>> Flags: Hidden, Archive >>>>>>> Name: system.LOG >>>>>>> Parent MFT Entry: 3982 Sequence: 2 >>>>>>> Allocated Size: 4096 Actual Size: 1024 >>>>>>> Created: 2004-09-02 08:00:12.000000000 (Hora oficial do Brasil) >>>>>>> File Modified: 2004-09-02 08:00:12.000000000 (Hora oficial do >>>>>>> Brasil) >>>>>>> MFT Modified: 2004-09-02 08:00:12.000000000 (Hora oficial do Brasil) >>>>>>> Accessed: 2004-09-02 08:00:12.000000000 (Hora oficial do Brasil) >>>>>>> >>>>>>> $ATTRIBUTE_LIST Attribute Values: >>>>>>> Type: 16-0 MFT Entry: 4106 VCN: 0 >>>>>>> Type: 48-4 MFT Entry: 4106 VCN: 0 >>>>>>> Type: 128-0 MFT Entry: 40678 VCN: 0 >>>>>>> >>>>>>> Attributes: >>>>>>> Type: $STANDARD_INFORMATION (16-0) Name: N/A Resident size: 72 >>>>>>> Type: $ATTRIBUTE_LIST (32-5) Name: N/A Resident size: 96 >>>>>>> Type: $FILE_NAME (48-4) Name: N/A Resident size: 86 >>>>>>> Type: $DATA (128-6) Name: N/A Non-Resident size: 1024 >>>>>>> init_size: 1024 >>>>>>> 847844 0 0 0 0 0 0 0 >>>>>>> 0 0 0 0 0 0 0 0 >>>>>>> 0 0 0 0 0 0 0 0 >>>>>>> 0 0 0 0 0 0 0 0 >>>>>>> 0 0 0 0 0 0 0 0 >>>>>>> 0 0 0 0 0 0 0 0 >>>>>>> 0 0 0 0 0 0 0 0 >>>>>>> 0 0 0 0 0 0 0 0 >>>>>>> 0 0 0 0 0 0 0 0 >>>>>>> 0 0 0 0 0 0 0 0 >>>>>>> 0 0 0 0 0 0 0 0 >>>>>>> 0 0 0 0 0 0 0 0 >>>>>>> 0 0 0 0 0 0 0 0 >>>>>>> 0 0 0 0 0 0 0 0 >>>>>>> 0 0 0 0 0 0 0 0 >>>>>>> 0 0 0 0 0 0 0 0 >>>>>>> 0 0 0 0 0 0 0 0 >>>>>>> 0 0 0 0 0 0 0 0 >>>>>>> 0 0 0 0 0 0 0 0 >>>>>>> 0 0 0 0 0 0 0 0 >>>>>>> 0 0 0 0 0 0 0 0 >>>>>>> 0 0 0 0 0 0 0 0 >>>>>>> 0 0 0 0 0 0 0 0 >>>>>>> 0 0 0 0 0 0 0 0 >>>>>>> 0 0 0 0 0 0 0 0 >>>>>>> 0 0 0 0 0 0 0 0 >>>>>>> 0 0 0 0 0 0 0 0 >>>>>>> 0 0 0 0 0 0 0 0 >>>>>>> 0 0 0 0 0 0 0 0 >>>>>>> 0 0 0 0 0 0 0 0 >>>>>>> 0 0 0 0 0 0 0 0 >>>>>>> 0 0 0 0 0 0 0 0 >>>>>>> 0 0 0 0 0 0 0 0 >>>>>>> 0 0 0 0 0 0 0 0 >>>>>>> 0 0 0 0 0 0 0 0 >>>>>>> 0 0 0 0 0 0 0 0 >>>>>>> 0 0 0 0 0 0 0 0 >>>>>>> 0 0 0 0 0 0 0 0 >>>>>>> 0 0 0 0 0 0 0 0 >>>>>>> 0 0 0 0 0 0 0 0 >>>>>>> 0 0 0 0 0 0 0 0 >>>>>>> 0 0 0 0 0 0 0 0 >>>>>>> 0 0 0 0 0 0 0 0 >>>>>>> 0 0 0 0 0 0 0 0 >>>>>>> 0 0 0 0 0 0 0 0 >>>>>>> 0 0 0 0 0 0 0 0 >>>>>>> 0 0 0 0 0 0 0 0 >>>>>>> 0 0 0 0 0 0 0 0 >>>>>>> 0 0 0 0 0 0 0 0 >>>>>>> 0 0 0 0 0 0 0 0 >>>>>>> 0 0 0 0 0 0 0 0 >>>>>>> 0 0 0 0 0 0 0 0 >>>>>>> 0 0 0 0 0 0 0 0 >>>>>>> 0 0 0 0 0 0 0 0 >>>>>>> 0 0 0 0 0 0 0 0 >>>>>>> 0 0 0 0 0 0 0 0 >>>>>>> 0 0 0 0 0 0 0 0 >>>>>>> 0 0 0 0 0 0 0 0 >>>>>>> 0 0 0 0 0 0 0 0 >>>>>>> 0 0 0 0 0 0 0 0 >>>>>>> 0 0 0 0 0 0 0 0 >>>>>>> 0 0 0 0 0 0 0 >>>>>>> >>>>>>> 2017-01-31 12:56 GMT-02:00 Brian Carrier <ca...@sl...>: >>>>>>> >>>>>>>> Hi Luis, >>>>>>>> >>>>>>>> My guess is that it's a file that has preallocated a large amount >>>>>>>> of space, but that has not fully used it yet. NTFS allows this. If you >>>>>>>> read the file, TSK will only show you the space that is used. Reading the >>>>>>>> slack, gives you the rest. >>>>>>>> >>>>>>>> If you run 'istat' on one of these files and send it along, we can >>>>>>>> confirm. >>>>>>>> >>>>>>>> thanks, >>>>>>>> brian >>>>>>>> >>>>>>>> >>>>>>>> On Tue, Jan 31, 2017 at 7:04 AM, Luís Filipe Nassif < >>>>>>>> lfc...@gm...> wrote: >>>>>>>> >>>>>>>>> Hi folks, >>>>>>>>> >>>>>>>>> I am upgrading to tsk-4.4 to benefit from the new support to >>>>>>>>> slackfiles from java bindings. But I noticed some slackfiles larger than >>>>>>>>> the cluster size (4k) are created in database. Some of them have megabytes >>>>>>>>> of size and its contents are accessible. Is it expected to have slackfiles >>>>>>>>> larger than cluster size? Could someone explain? >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Luis Nassif >>>>>>>>> >>>>>>>>> ------------------------------------------------------------ >>>>>>>>> ------------------ >>>>>>>>> Check out the vibrant tech community on one of the world's most >>>>>>>>> engaging tech sites, SlashDot.org! http://sdm.link/slashdot >>>>>>>>> _______________________________________________ >>>>>>>>> sleuthkit-users mailing list >>>>>>>>> https://lists.sourceforge.net/lists/listinfo/sleuthkit-users >>>>>>>>> http://www.sleuthkit.org >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> > |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X