MFT moved away by FastFill(WithShuffling) (4.2.8)

[ff_mfg]

I'm not sure if this is a bug, but it surprised me a lot. I saw FastFill(WithShuffling) move MFT away (used script is essentially OptimizeWeekly with 1 extra zone, so there's nothing weird going on there). I thought it shouldn't be possible? Already processed files shouldn't be touched, right?

[jeroen]

Already processed files will not be touched. There are a couple of possible explanations for what you saw, the first possibility that comes to mind is that you misinterpreted what you saw. See the I have a problem! page for instructions about how to make a detailed debug logfile.

[ff_mfg]

Sadly, no, this is exactly what I saw. I've seen it a number of times now. I noticed that it tend to happen when the end of the zone is near $MFT (not really sure though, might be just a coincidence).

Today I finally caught it with debuglog on:
19:19:50       Starting to fill the gap at LCN=914722, size=24571 clusters.
19:19:50         Finished creating array, 9 items.
19:19:50         There are 9 movable items above the gap, smallest is 141 clusters, largest is 15699 clusters.
19:19:50         Finished sorting the array.
19:19:50         The gap cannot be perfectly filled, 58 clusters will remain.
19:19:50         Trying to move away the item above the gap.
19:19:50           I want to move 36517 clusters at LCN=939293 of item 'C:\$MFT'.
19:19:50             Looking for the first gap of 36517 clusters after Lcn=1009204, or the largest gap.
19:19:50               Gap found: Lcn=1041885, Size=84982
19:19:50             Moving 'C:\$MFT'
19:19:50               Moving 36517 clusters to Lcn=1041885.
19:19:50               API is moving 36517 clusters at offset=4 to Lcn=1041885.
19:19:56               Getting fragment list for: C:\$MFT
19:19:56                 Extent: Lcn=601267, Vcn=0, NextVcn=4
19:19:56                 Extent: Lcn=1041885, Vcn=4, NextVcn=36521
19:19:56                 Translating into fragment tree....
19:19:56                 Counting fragments....
19:19:56               Checking block at Lcn=1041885, offset=0, size=36517 clusters.
19:19:56                 Block was moved correctly.
19:19:56         The gap was succesfully enlarged, trying again to find a perfect fit.

Script and debuglog attached.

[jeroen]

Sadly, no, this is exactly what I saw. I've seen it a number of times now.

Thanks you very much for the logfile, I appreciate it. I have looked at it and to my great surprise I see that you are correct, the MFT is moved away while vacating a gap. That should not happen, it is not as intended. I will take a look and fix it in the next release.