On a mobile UBS HDD I defrag'd the drive and got some holes with free space. To eleminate them, I started a "Defrag free space", WITHOUT the "allow fragmentation".
That should close the holes without creating creating fragmentation - I expect that files are pulled together if there's nothing suitabe to fill in the gap. Instead of that Defraggler used a large file to fill in the gaps, by the way fragmenting that file.
I have not tried the procedure with "allow fragmentation", but maybe the menu entries need to be swapped ?
Yep, you've stumbled upon a bug that was ""introduced"" in v1.20 and this isn't corrected in v1.21. This is clearly a bug because in v1.19 and previous versions it worked well.
In DF there're two options to defrag the freespace:
1. Defrag freespace
2. Defrag freespace (allowing fragmentation).
In both v1.20 and v1.21 happens the following:
A. When the user chooses option (1 DF performs process #2.
B. When the user chooses option (2 DF performs process #1.
I have first hand experience because I use these two options - at least - once a week.
I have to correct my previous post in this thread. This freespace defragment bug wasn't included in v1.18 but was present in versions v1.19, v1.20 and v1.21.
So the question becomes: When are the Piriform folks going to fix this bug in Defraggler ???
I don't think it matters if the free space is defragged and all the files are squeezed together at the beginning of the disk. A few holes scattered about should not effect performance. What matters is that the individual files are defragged to optimize speed by gaining a few seconds.
And there's no point in being vexed over a partly fragged partition. If you could get it all together perfectly it would become fragged again soon. So what did you gain?
The point of this thread was that DF has a bug. That bug was introduced in v1.19 and hasn't been corrected in all higher versions. Fixing this bug in DF is simply a matter of swapping two pointers in the program code but the Piriform folks don't seem to bother to fix this bug.
I do not really think that this is a bug. I think it is just a matter of interpretation, and what they should do is change the captions to clarify this.
What I mean by a matter of interpretation is it depends on what "allow fragmentation" applies to. If this is meant to apply to file fragmentation then I can see how it would seem to be working incorrectly. If, however, this is meant to apply to free space fragmentation then I believe it is working correctly.
I think that Piriform should update the captions to say something like "allow free-space fragmentation" otherwise people will continue to misunderstand these options.
I don't think it matters if the free space is defragged and all the files are squeezed together at the beginning of the disk. A few holes scattered about should not effect performance. What matters is that the individual files are defragged to optimize speed by gaining a few seconds.
And there's no point in being vexed over a partly fragged partition. If you could get it all together perfectly it would become fragged again soon. So what did you gain?
There is a much bigger issue here:
- Defraggler should not be doing the opposite of what you click. It should obey your command.
- Defraggler should not call it "consolidation" if that isn't what it does.
Hopefully, version 2 will fix this. Anyone know if 2 is better?