8 replies to this topic

[wraithdu]

I am writing a UDF that utilizes the defragmentation API (specifically FSCTL_GET_RETRIEVAL_POINTERS and IOCTL_VOLUME_LOGICAL_TO_PHYSICAL) to map a file's location on disk. The goal is to use this to update my secure file deletion script. I have a few unanswered questions though regarding the filesystem that are fairly important. Any takers?

1) Are file extents (not including the final extent or files taking up only a single extent) guaranteed to completely fill a block of clusters, ie no unused bytes at the end of the last cluster in the block?

2) Is a disk cluster guaranteed to only contain data from one file? So a 2K file only takes up part of a 4K cluster... can the rest of that cluster contain data from another file? If so, same question regarding a single sector (usually 512 bytes, vs a 4K cluster)?

I think the answer is yes to both question... but that's a dangerous assumption when you're writing directly to the disk.

[BrewManNH]

1 file per cluster, 1 file per sector. Not sure what a file extent is, but if you have a 4K cluster size and a 1K file, that file will inhabit one cluster, and approx. 3K of that cluster will be unknown data.

[wraithdu]

Thank you. And an extent is a contiguous block of clusters belonging to a file, ie an extent is one fragment of a fragmented file. While the clusters that make up an extent must be contiguous, the extents that make up a file can be located physically anywhere on the disk, hence file fragmentation and the need to defragment.

So that just leaves #1 above. I'm pretty sure the answer is yes. I've successfully tested reading the mapped extents in order, directly from the disk, and comparing the rebuilt file to the original. This is actually an interesting process when it comes to compressed and EFS encrypted files. The original file cannot be trivially recovered since the OS implements the compression or encryption transparently, and it doesn't know the rebuilt file is either compressed or encrypted. But the the rebuilt file contains the actual compressed or encrypted data as it is stored on disk.

Edited by wraithdu, 28 September 2011 - 10:15 PM.

[BrewManNH]

As long as the file fragment you're dealing with isn't the last one, then it will be filled with the file's information and nothing else, because the last one is the only one that may or may not fill that last cluster.

[wraithdu]

Thanks for confirming what I originally suspected.

[KaFu]

Maybe this is useful to you too ...

Edit: See below...

Edited by KaFu, 29 September 2011 - 07:56 AM.

[AdmiralAlkex]

Maybe this is useful to you too ...

[#10171] You do not have permission to view this attachment.

Heh?

[KaFu]

Not sure what went wrong. It was an attachment I added to another post already, maybe that's the problem. I've re-uploaded it now.

 NTFS Documentation.pdf.zip   273.67K   88 downloads

[AdmiralAlkex]

That worked. Quite a lot of information in there!