Stop / Restart -> No Tabula Rasa

[HolyMan]

If I stop MyDefrag, it is usually because it is doing something that I definitely do not want it to do. Like moving away a large file in tiny bits, something that tends to go slower and slower. Especially annoying if you want to write 35 MB files in a 150 MB hole so there is abso;ute;y no need to move for that file.
If I break MyDefrag while it is doing that, it writes the first cluster of the file to the first cluster of the free space that I just created. If I restart MyDefrag to go on there it will move away that cluster and then proceed moving away the rest of the file as if it is important unfinished business that needs to be done before anything else.
If I try to cheat the program by starting somewhere a bit before the gap, it will just go on to the first cluster of the file and then starts moving it as if this is the only thing I ever would want.
Why is MyDefrag so conceited?

[HolyMan]

It actually places the first cluster there at the next MyDefrag startup. (At least it says it is doing that on the screen.)

[jeroen]

I don't understand what you are trying to do, but it sounds as if you are trying to force the program to do something it was not designed for. Perhaps you can post your script and logfiles.

[HolyMan]

Here it is. I could not reproduce the problem entirely. The single first cluster was moved to LCN 2 this time. It will take a while before the situation on the disk will be "right" again, but I send you the logfile anyway. This is what it seems to do:

Code:

23:10:35           Starting block analysis for VacateUntilEnoughFree, StartLcn=204176, MinimumClusters=26272
23:10:35             Block: LCN=204176, Clusters=9344, Path='D:\OldFile 1,x'
23:10:35             Block: LCN=213520, Clusters=82954, gap
23:10:35             Block: LCN=296474, Clusters=28706, Path='D:\Big Fragmented File,x'

It notices the gap and sees parts of the file. The gap is 92000 LCN's, where the file to be placed is only 26272 LCN's. So no need to clean any clusters. But MyDefrag does the moving anyway.

The script used might look familiar to you. I am kind of a synergy-minded person.

[jeroen]

Your script forces MyDefrag to begin a zone at a specific location on the disk, then selects files with a lot of fragments, and then sorts the selected files by size. All the other files on the disk are not selected, so MyDefrag will move them to above the selected files. You can use the ExcludeFiles command to make all the other files unmovable, or you could add a zone before your destination zone, for all those other files.

[HolyMan]

I know what my script does. But why does it try to move away that big file when there is lots of free space and the files to be placed easily fit in the gap?
This phenomenon occurs when I restart after I closed down MyDefrag while it was moving this big part. (That is why I  closed MyDefrag then. Because I did not want it to move the file at that moment.)
The script was a testscript to provoke the action. It did not entirely reproduce it because the single begin cluster of the big file that was being moved was written to another location (and I accidentally wrote 1000 instead of 100 in the fragment restriction, so the difference in filesize was not that impressive. It did show that the big file was being moved without need though.

Anyway. I managed to work around it so for now it is not my problem anymore.

[jeroen]

The SortBySize wants to place the selected files at the beginning of the zone. Exactly at the beginning of the zone. But that big file you are talking about is in the way, and it is not selected, so MyDefrag thinks it belongs to another zone and will move it away, to make room for the files that have been selected.