Not really. It's a totally different strategy.
Today:
1. got this file A, it has these chunks fragmented A1 there A2 there and A3 there
2. I've to place these chunks there L1-L3... oh wait it's occupied, gotta free up some space first
3. Moving those chunks C1-C3 occupying the space L1-L3 out of the way to a temporary location TL1-TL3 on the drive
4. Now moving A1-A3 to final location L1-L3
5. Next file B, it has the chunks B1-B4 located at L5, TL1, TL3 and L7
6. Gotta move it to L4-L7, L4 is free great... oh wait L5 is occupied, gotta free up space again
7. Moving L5-L7 to TL4-TL6
8. Now moving TL4 (was L5) to L4, TL1 to L5, TL3 to L6 and TL6 (was L7) to L7
There are a lot of physical relocations which are not necessary at all and which costs a lot of time.
My idea is to perform a virtual defrag on a copy of the file chunk allocation table defraggler gets anyway by it's analysis.
1. Get file chunk allocation table (T1) by analysing the drive, display the chunks in the gui (as of today already)
2. make an internal copy (T2) of that table (T1) and perform a virtual defrag only on T2 without moving any file at all, only to get a final layout where all chunks ought to be after a defrag.
3. Now look for a free cluster in T1 and move the belonging chunks (according to T2) there, update T1
4. repeat until no free cluster is available anymore
5. If all clusters in T1 equal T2, it's finished, else
6. check a file which still has to be defragmented and move all chunks to a temporary location, this frees up some clusters.
7. Restart loop at 3.
I'll bet the time it takes to virtually defrag T2 will be saved and much more because of avoiding so much unnecessary physical cluster moves to temporary locations and back to their final locations. Especially when we consider HDDs.