I have a question regarding the next version, but I don't want to know anything about the release date: I just want to know if there is something big scheduled for the next version of MyDefrag, or if Jeroen took a little break from it.

Anyway, thank you so much for what you have done until now

Byee

There is Puran Defrag too.

I solved the problem. I did a deep defragmentation pass with Puran Defrag, and now all those Crypto folder/files have been consolidated. However, I lost the MyDefrag disk optimization due to Puran Defrag defragmentation algorithm. Maybe next week I'll do another monthly pass with MyDefrag to reorganize my disk. In the mean while I'll do some performance tests using the Puran Defrag PIOZR optimization strategy to see if it's a good think or not. I'll let you know.

However, thanks very much for the support

So, as I was writing before (and in other threads too), if FastFill will consider Wrap-around fragmentation, then the problem you just described shouldn't be anymore . So I continue to not understand what are these cases where FastFill (with wrap around) might make things worse...

It will not defragment a file fragmented due to wrap around if IgnoreWrapAroundFragmentation is True. So it respect the concept of Wrap-around fragmentation.

Actually, in the current version of MyDefrag, the Defragment() command works in this way ... there is no "Defragment(WrapAround)" right now.

I think MyDefrag should follow only one concept for defragmentation. You want to go with Wrap-around fragmentation? Ok, all the FileAction commands should work considering Wrap-around fragmentation. You want to go without Wrap-around fragmentation? Then all the FileAction commands shouldn't wrap around files, even commands like SortByXXX. In other words, all the commands should respect the active philosophy ... and I think this is quite important, because right now there are commands in MyDefrag that don't consider Wrap-around fragmentation even if the flag of WrapAroundFragmentation is set to true.

But please as an option. I don't want FastFill to wrap files around.

FastFill should follow the active settings (for example if IgnoreWrapAroundFragmentation is true then it should wrap around, otherwise should act like now).

I don't think we need FastFill to be able to use the wrap-around concept. It might help in some cases and might make things worse in other cases - at least until the whole concept of wrap-around fragmentation is revisited.

And what are these cases where it might make things worse?

But isn't MyDefrag designed with the Wrap-around fragmentation in mind? Fastfill is often used because it's called by weekly and daily scripts, and it might have some problems in compacting files if there are many unmovable block in the drive (for example like the Microsoft Crypto folders). Instead, SortByXXX doesn't seem to have these problems, but isn't used so often either (by concept, one time a month). It looks like the daily and weekly scripts don't follow too much the concept of Wrap-around fragmentation. It might preserve the already present wrapped around files, but nothing more. And maybe not even that: if you're using FastFill(WithShuffling), it can destroy wrapped around positioning because if it wants to enlarge a gap, and the next file is a wrapped around one, it will move that file away, compacting it. Then, when it will move it back, this file will not be wrapped around anymore...

If I've a file fragmented in, for example, 100 parts, and under all these parts I've 2 gaps that together are big enough to hold that file but divided only by unmovable data, how does FastFill() act? It will place that file in these 2 gaps, resulting in a file fragmented only in 2 parts? Or to reach this result is mandatory to execute the Defragment() action first?

Thanks

[MoveToEndOfDisk(WithShuffling)]

Hi all! I noticed this behavior using the action MoveToEndOfDisk(): if there are no more files small enough to fill a gap at the end of the disk, this gap will be skipped. And this is an expected behavior, so it's ok. However, it would be nice to have a MoveToEndOfDisk(WithShuffling), acting like the opposite of FastFill(WithShuffling): if MoveToEndOfDisk encounters a gap that cannot be perfectly filled, then it will move the file just under the gap away and try again to perfectly fill that gap. What do you think?

Okay, I'll follow your advice ... but I've an additional question about this: if one day I find myself with not too much space, can this be an additional problem to defragment my files? Or since these are unmovable blocks MyDefrag will pass on, thanks to the Wrap-around fragmentation concept?

[Access denied]

Code:

16:19:07         I want to move 1 clusters at LCN=386230 of item 'C:\ProgramData\Microsoft\Crypto\RSA\MachineKeys\c2a487a026c77654a612013b837b7021_2403006b-a89b-44d7-b154-a7110b611993' (Inode=60306).
16:19:07           Moving 'C:\ProgramData\Microsoft\Crypto\RSA\MachineKeys\c2a487a026c77654a612013b837b7021_2403006b-a89b-44d7-b154-a7110b611993' (Inode=60306)
16:19:07             Could not open: [5] Accesso negato.
16:19:07             Changing the item into 'not movable'.
16:19:07             Calculating the end of the zone.
16:19:07               ZoneBegin = 0
16:19:07               Number of clusters in selected items = 478601
16:19:07               Iteration 1: 39 unmovable clusters between 0 and 478601, ZoneEnd = 478640
16:19:07               Iteration 2: 39 unmovable clusters between 0 and 478640, ZoneEnd = 478640
16:19:07               New ZoneEnd = 478640

I think you're right: Access denied. In my system I've only 1 user, me, without password. Is there a way to gain the permission to access these files? Or perhaps a way to "compat" these files like the pagefile's trick? Also, some of you have Windows 7 Ultimate x64? If yes, are you experiencing this problem of the Crypto folder?

Just played a bit with MyDefrag, and I found that if I close it during or right after the unmovable data loading step, then it "forgets" the unmovable files. The file "MyDefrag.dat" suddenly becomes very small (1kb) and if I restart MyDefrag it won't load unmovable data anymore, until during a defragmentation pass it encounters again some unmovable data... 

Just tried, and these little red dots are still there. Here is a portion of MyDefrag map enlarged at 512x ...   

Ok, good idea, in the next days I'll try to defrag in Safe mode and see what happens ... thanks for the advice