Re: [sleuthkit-users] TSK-4.4 and SlackFiles
Brought to you by:
carrier
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 >>>> >>>> >>> >> > |