Move to End of Drive: wrong handling of compressed NTFS files

[Eld0r]

I saw the green highlight for writing a file is much bigger, than the yellow for reading. 

For normal defrags I would think of sth. like a view bug. Of course the space behind the file is free, so a normal defrag to the lower sectors create no gaps.

But I got gaps of 3GiB free space between the moved files and the actual End of Drive.

 

I only noticed, because I got big and effectice compressed backups files. So this 4GiB files are compressed to 1GiB with NTFS. Defraggler highlight the correct sectors in overview. I marked the files and told Defraggler to move them to End of Drive.

 

Conclution: Defraggler checks the space for a uncompressed file and aligns the compressed file like it is not.

And this repeats for all compressed files.
The gaps can -of courcse- only be filled with files <3GiB.

When they are smaller and also compressed there is a gap again (behind and also before them).

And so on...

 

Hope you can fix the calculation/moving of compressed NTFS files so Move to End of Drive works again.

I volunteer to become a beta tester.

 

regards

Eld0r

[Eld0r]

Seem like it's the general handling of compressed files.
If possible please try to use always the property 'size on disk' instead of just 'size' for files & directories.

 

Or is it the standard defragmentation API from Microsoft?

Actually it should able to handle this decades old feature of NTFS.

 

Would be nice to store the files without gaps at the end of disk. 

[Andavari]

Previously when asked they stated it using the Windows defrag API.

 

As for handling of NTFS compressed files, I've read in the past that it can give defrag tools using the Windows defrag API (which most use) issues but mostly what I got out of it was their ability to fill gaps.

 

Then again you'll also have to consider the MFT Reserved Zone, some defrag tools clearly show it in the drive/defrag map whereas others don't so it can look like there's a large amount of blank space in between files in defrag tools that don't show it.

 

I don't know if this Microsoft Windows 2000 defragmenation article is current for modern defrag software or not, but one line in it was interesting:

 

It's the file system, not Disk Defragmenter, that takes care of all data movement.

[Eld0r]

Si

 

So I think the reason is the wrong destination cluster.

when you read attributes of the same compressed file and get for size 4GiB and for file size on disk 1GiB.

And move it to end of drive for size - its only possible with a 3GiB gap after it.

 

So calculation for destination cluster should be G := GetTheLastBigEnouthGap (for size on disk)

And then use the IndexOfLastCluster (of G) minus the AnmountOfClusters (for size on disk)

So you get the correct Position for the C := FirstClusterOfCompressedFile.

 

I would bet, if you told the API to move the file to this Cluster C, then there is no gap after moved compressed files any more.

Of course any calculation should use size on disk, because this shows the true physical size wich is important for defragmentation.