Thanks Moderator for clarifying your policy.
First of all, I want to express my extreme appreciation for such a powerful and easy to use app provided in the spirit of giving freely. Hopefully this discussion might help add a bit of value to that tool by focusing on an area that has potential improvement.
Since the solution I posted directly solves the inability of DF to move unmovable files (even after reboot defrag) from the free space, I respectfully submit that my solution is very relevent to this thread.
I fully support minimizing double posting. The other posting content addressed a significantly different issue: invalid bad clusters not being dealt with, which the same partition squeeze seems to solve. I agree that everyone should ALWAYS do image backups when they take extreme measures to more fully deal with all the potential garbage windows keeps, which is why it is the 1st step in my process enumerated in my prior posting.
I hope that everyone understands that anything, includingh clearing the free space with DF, that fills up the partition (squeezing it to minimum has a similar effect) can cause the loss of many if not all system restore points. I love the DF tools feature to easily see restore points and remove all but the most current - much more convenient and quicker than the way windows buries it in a subtle submenu, and again, potentially very hard on a casual user.
BTW, answering an old thread much later does at least provide a potential answer that is still very relevent even now to an old issue that was never solved. Just because I didn't spot that thread until now doesn't mean the issue doesn't deserve a useful response.
More observations on the current topic - back to basics ...
Alot of folks have expressed a lot of frustration with not being able to defrag free space completely, especially when they wanted to reset the pagefile and hybernation files to be contiguous directly after all files on a totally defragmented drive.
Again, simply resizing the partition to minimum size (and "applying") and then resizing back to original size eliminates ALL of the free space fragmentation.
It is a partition operation that warrants caution, and it appears to be benign in my experience. Since this simple process handles unmoveable files, it is much more effective that the free space defrag (and potentially a lot quicker). I have never had a problem doing this. Note that a freshly formatted XP partition puts the system files somewhat down the free space and those files and structures are moved to the beginning of the drive by the minimum size resize process. I understand that this is the fastest part of the drive, so this may be another possible benefit?
Restoring an image of an o/s partition to a different sized partition some times causes a sytem to stop booting, and every time it has been fixed by setting the o/s partition Active (somehow reset by restore).
I used the XP SP3 Disk Management tool to reformat a 20 Gig non-o/s data partition. Running Defraggler Analysis now displays 3 full rows (out of 23) of purple (MFT per color legend), or 13% (2.61 Gig!) of the drive space. The first purple block shows the $MFT at 52k, $MFTMirr at 4k, the $Logfile at 65.5k, plus $UpCase, $Bitmap, $Secure:$SDH. The XP Disk Defragmenter reports 66MB used of 20.15 GB and confirms $MFT size at 52k (51% in use) in 2 fragments. Chkdsk also reports the $Logfile as 65.6k.
An image backup/restore (without resizing) using Backupper did not eliminate the purple blocks (but did move them down a bit so that substantial free space now appears above them. Reformatting or Deleting and recreating the partition using MiniTools Partition Wizard also didn't seem to affect them (space above still there too). Reformatting using Format d: also had little effect (placed 3 rows of purple about 1/4 down from start of partition, about the same place). Finally, minimizing the partition size and moving it up a gig, doing an image backup using Backupper, resizing back to full size and starting at original position, then restoring squeezed backup (using the advanced restore feature to reset the minimal backup partition size to the original full partition size during the restore process) produced about the same size contiguous purple area but moved it much closer to the start (starting about where the squeezed partition start was moved to?).
All of this leads me to conclude that the large purple area is, in the end, expected windows behavior, although, for some odd reason, a few of the partitions do not have nearly as large of area even though they are the same partition size on freshly partitoned drives. Wierd!
Perhaps the 2.6 GB is reserved for the $MFT plus other NTFS system files? This seems way overboard to me, but I cannot tell since ALL other purple blocks (after the 1st) are reported by DF as "no files are in block"?
As others have commented, alot of confusion, concern, speculation, and much effort messing with this trying to minimize or at least consolidate this large area could be avoided by reporting the actual system files (or at least generic "system files") rather than "no files".
Now if DF only used the windows start up order file contents to optimize windows start up file placements like several other defrag utilities do, I would be even more impressed! I'll post to feature request list if I don't find it so feel free to delete the previous sentence if I forget to minimize double posting.
Hope this helps!
