why fsutil.exe takes less time to write a huge file into disk than programmatically?

this question is according to this topic: creating a huge dummy file in a matter of seconds in c#

I just checked the fsutil.exe in xp/vista/seven to write a huge amount of dummy data into storage disk and it takes less time to write such a big file in comparison to programmaticly way.

When I'm trying to do the same thing with the help of .net it will take considerably more time than fsutil.exe.

note: I know that .net don't use native code because of that I just checked this issue with native api too like following:

long int size = DiskFree('L' - 64);
const char* full = "fulldisk.dsk";
__try{
Application->ProcessMessages();
HANDLE hf = CreateFile(full,
                       GENERIC_WRITE,
                       0,
                       0,
                       CREATE_ALWAYS,
                       0,
                       0);
SetFilePointer(hf, size, 0, FILE_BEGIN);
SetEndOfFile(hf);
CloseHandle(hf);
}__finally{
    ShowMessage("Finished");
    exit(0);

and the answer was as equal as .net results.

but with the help of fsutil.exe it only takes less duration than above or .net approaches say it is 2 times faster

example : for writing 400mb with .net it will take ~40 secs the same amount with fsutil.exe will take around 20secs or less.

is there any explanation about that? or which function fsutil.exe does use which has this significance speed to write?

I don't know exactly what fsutil is doing, but I do know of two ways to write a large file that are faster than what you've done above (or seeking to the length you want and writing a zero, which has the same result).

The problem with those approaches is that they zero-fill the file at the time you do the write.

You can avoid the zero-fill by either:

1. Creating a sparse file. The size is marked where you want it, but the data doesn't actually exist on disk until you write it. All reads of the unwritten areas will return zeros.
2. Using the SetFileValidData function to set the valid data length without zeroing the file first. However, due to potential security issues, this command requires elevated permissions.