Earlier blogs described the problem of supplying NTFS enough information so that it could make an appropriate placement of a file on an NTFS volume to avoid fragmentation. We concluded that setting the file size information using a SetFileInformation API was not sufficient.
I updated my code – here is the pseudo code from the previous blog with one modification – this in attempt to provide NTFS even more information.
Open source file
Open destination file
GetFileSizeInformationForSourceFile();
SetFileSizeInformationForDestinationFile();
SetFileValidData(); // for destination file
While (!EndOfSourceFile)
{
Read(SourceFile)
CheckForEndOfFile
WriteToDestinationFile (including write a partial buffer if any)
}
Close source file
Close destination file
The one modification is the call to SetFileValidData. As the MSDN documentation points out, this has security implications in that any data “left over” on the disk blocks allocated to the file can now be potentially available to anybody who can open the file. But since our copy applet will fully write all blocks of the file, this security concern does not apply in our case.
Contig now shows that the file is unfragmented!
Would it be possible for NTFS to determine the file size and allocated disk blocks accordingly without the need of this API? Only somebody from the NTFS team at Microsoft can answer that question.
But in the meanwhile, application developers have a way to make sure that they supply NTFS all the information it needs to try and avoid file fragmentation.
winntfs 