ifind: do not walk over sparse blocks

[noxdafox]

Use TSK_FS_FILE_WALK_FLAG_NOSPARSE flag in tsk_fs_attr_walk instead of
testing TSK_FS_BLOCK_FLAG_SPARSE in the callback.

Signed-off-by: Matteo Cafasso noxdafox@gmail.com

[noxdafox]

This was mentioned in the following email:

https://sourceforge.net/p/sleuthkit/mailman/message/35389465/

[bcarrier]

The comments on the callback are technically correct, but perhaps not complete. The address is correct only for RAW (and not SPARSE or COMPRESSED).

The reason is because SPARSE blocks do not have an address and COMPRESSED data does not always align with a single block. For example, NTFS may store 8 blocks of data into 4 blocks, but the callback gets called 8 times (but we can't map the data in the buffer for that callback to a specific block anymore).

But, in the above example, 4 of the 8 callback calls will be given an address so that tools like 'ifind' can at least map that the address corresponds to the file.

So, I think ifind is correct, but perhaps the docs for the callback could be expanded to reflect this ambiguity that the address is relevant when it is COMPRESSED, but perhaps not for that exact buffer of data.

[noxdafox]

The PR is not contemplating the COMPRESSED blocks in fact. It's just preventing to call the callback on sparse blocks which is useless overhead (both executing and reading the code). So it's more of a code-cleanup PR.

I am curious about what said about COMPRESSED blocks. Is this behaviour a limit of the walk API or is it a feature of NTFS FS? In the given example, what are the latter 4 blocks pointing at? I guess they are not allocated or the compression itself would be quite pointless.

I can try to improve the documentation regarding COMPRESSED blocks. Could you please point me its location? As mentioned in the other PR #689 I could not find it in the code.

EDIT: @bcarrier, from Chapt 11 of "Filesystem Forensics Analysis" I got my answers, thanks anyway.