3

In the Windows OS command line, when I need to quickly create a file of arbitrary size, I use the command:

fsutil file createnew <filename> <size_in_bytes>

I recently created a 100GB file using this native tool, and I was surprised that it took less than 500ms to create the file. I created the file on a platter-based hard drive that was previously filled with data.

Out of curiosity, I opened the file in a hex editor, and it appeared to be completely empty (admittedly, I didn't manually inspect all 100GB). I was expecting it to be filled with the previous contents of the hard drive, given that there is no way it just wrote 100GB of data in 500ms.

What is fsutil file createnew actually doing? And, depending on what it actually does, can it be used as a low-security rapid wipe technique (single-pass)?

Amazon Dies In Darkness
  • 9,990

1 Answers1

3

I was expecting it to be filled with the previous contents of the hard drive,

Multi-user operating systems generally do not allow this to happen, as it would be an unnecessarily easy way to bypass OS-level file protection features, and at least for Windows this is explicitly part of its security certification.

What is fsutil file createnew actually doing?

There are at least two options, I suspect (but haven't checked) that fsutil uses the first – it relies on the OS to keep track of "end of data".

  • The filesystem may keep two separate pointers – the 'end of file' as well as 'end of valid data'. This is explicitly how NTFS works in Windows.

    You can call SetEndOfFile() (corresponding to Linux ftruncate()) to create a large file with no data, and the space between "end of valid data" and "end of file" will automatically return all 0x00 bytes when read.

    (Privileged accounts can actually use the SetFileValidData() call to force the OS to return data that is already on disk, but it's not a commonly used operation.)

  • If the filesystem is extent-based, then it keeps track not of individual disk clusters, but of whole contiguous 'start-end' ranges that comprise the file. This allows creating sparse files, in which some extents are simply marked as not having any physical allocation at all (i.e. are "holes") – those locations will return 0x00 when read (until something else is written there, of course).

    Generally, simply seeking beyond the end of file and proceeding to write will automatically result in a sparse file if possible.

fsutil has subcommands to inspect both the "valid data" pointer and the extent list of a file.

There are filesystems which don't support these techniques (e.g. FAT), in which case the OS will need to explicitly zero out the corresponding disk area.

And, depending on what it actually does, can it be used as a low-security rapid wipe technique (single-pass)?

No, not on mechanical disks.

grawity
  • 501,077