MyDefrag 4.1.2 flags many files as unmovable, even after earlier successful move

[ossat]

When running MyDefrag 4.1.2 on a 200MBytes NTFS partition containing around 8000 files and 700 directories, MyDefrag ends up flagging 7540 files & directories as unmovable. Numerous files, which have been moved successfully by MyDefrag a short while earlier in the defragmentation process, are suddenly flagged unmovable in a later, unsuccessful attempt to move them again.
It appears that MyDefrag fails to move a file (and thus flags the file as unmovable) whenever MyDefrag attempts to move a file that is larger than the size of the next available gap (e.g. trying to move a 59 clusters long file, when the next available gap is only 12 clusters wide). MyDefrag will attempt to move file after file into that gap and all moves of files larger than the gap will fail, resulting in those file being flagged as unmovable. This is despite the fact that MyDefrag reports in the debug log file that it attempted to move only a file fragment of the size of the gap to fill that gap. Nevertheless, the move fails.
Going down the list of files, MyDefrag will eventually reach a file that happens to be equal to or smaller than the width of the next available gap, resulting in a successful move of this file into the gap.

This issue might have perhaps the same root cause as the issue outlined in this post

The attached file contains an analysis of the issue with supporting information from the debug log file.

[usch]

http://www.mydefrag.com/forum/index.php?topic=2322 ?

[jeroen]

Thanks for posting your error report, I appreciate it. Do you think "usch" is right and that your problem is the same as in the thread he has mentioned? I have not yet had time to look in detail at your very impressive but rather long PDF file.

[ossat]

First step: the common underlying issue
I tend to believe that both the above issue encountered during SortBy and the issue encountered during FastFill(WithShuffling) are two different consequences of the same underlying problem:
   What interpretation gives MyDefrag to  “Error: [5] Access is denied”?

• (a) MyDefrag believes that the file to be moved is not accessible, thus flagging the file as “not movable”
• (b) MyDefrag believes that the target location (i.e. the gap into which the file should be moved) is already occupied by something else

Based on what I could understand from the debug log files, it appears that MyDefrag interprets “Error: [5] Access is denied” as case (a) (at least for all the cases of “Error: [5] Access is denied” I have encountered so far). Is this correct?

Microsoft documentation of the FSCTL_MOVE_FILE control code seems to indicate that “Error: [5] Access is denied” means case (b):

ERROR_ACCESS_DENIED: One or more of the logical clusters to which the file's virtual clusters are to be moved is an allocated cluster.

As a first step, MyDefrag interpretation of “Error: [5] Access is denied” needs to be clarified and fixed. If “Error: [5] Access is denied” can mean sometimes case (a) and other times case (b), than MyDefrag would have to clearly identify which case it is and proceed accordingly.

Once this interpretation problem is fixed, than the issues related to case (b) will naturally become more visible (because of correct interpretation) and thus easier to spot and fix.

Second step: the differences between the SortBy issue and the FastFill(WithShuffling) issue
Based on my understanding, both the SortBy issue and the FastFill(WithShuffling) issue are case (b), i.e. part (or all) of the target location is already occupied. However, the reason appears to be different:

• SortBy issue: it appears that MyDefrag is trying to move a whole file into a gap that is narrower than the file size (e.g. moving a 59 clusters file into a 14 clusters wide gap). Although MyDefrag reports in the debug log file that it is moving only a fragment of the file into the gap, other hints in the debug log file seems to indicate that, in fact, MyDefrag is not moving just a fragment but is rather trying to move the whole file into the gap.
• FastFill(WithShuffling) issue: it appears that MyDefrag is trying to move a file to a location that is already occupied. This is based on the following observations in the file MyDefrag_WS.debuglog:
  

  File to be moved Target location Hint that the target location is already occupied C:\Documents and Settings\henrik\Lokale indstillinger\Temporary Internet Files\Content.IE5\2OIQOJYM\Column2D[2].swf (see line <10'519>) LCN=921375 (see line <10'520>) At line <10'529>, one can see that the gap starts at LCN=921376 (i.e. not 921375) C:\WINDOWS\SoftwareDistribution\Download\cac6588caa53ab75a105faefbbe7bc62\SP3GDR\ieframe.dll (see line <10'603>) LCN=0 (see line <10'604>) At line <394>, it is stated that LCN=0 is occupied by unmovable data C:\WINDOWS\SoftwareDistribution\Download\cac6588caa53ab75a105faefbbe7bc62\SP3GDR\mshtml.dll (see line <10'626>) LCN=0 (see line <10'627>) At line <394>, it is stated that LCN=0 is occupied by unmovable data

[ossat]

Follow up of this issue is here.

[jeroen]

Based on what I could understand from the debug log files, it appears that MyDefrag interprets “Error: [5] Access is denied” as case (a) (at least for all the cases of “Error: [5] Access is denied” I have encountered so far). Is this correct?

Yes and no. I am sorry to give you such a short answer, but I don't have time to answer in detail.