How does FastFill() handle fragmented files

[ScorpionGTfx]

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

[jeroen]

FastFill does not do wrap-around.

[ScorpionGTfx]

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...

[jeroen]

But isn't MyDefrag designed with the Wrap-around fragmentation in mind?

Not exactly, no. FastFill was there long before I introduced the wrap-around concept. Perhaps in the future I will change FastFill so it will span it's scope across unmovable data, but at the moment it only looks at 1 gap at a time.

[BloodySword]

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

[Kasuha]

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.
What FastFill could handle better are fragmented files - like, normally fragmented, not wrapped around something. In my opinion it should be able (again as an option) to use individual file fragments for filling gaps instead of whole files.
At present, if someone has a partition made of database files, these files can be defragmented using defragment(chunksize) command leaving them fragmeted but in reasonably sized fragments - but at present there is no command that would be able to reduce gaps in between these chunks.

[BloodySword]

FastFill() should stay as is. But it should always try to use files from the end of the zone.

Using fragments to fill gaps is a bad idea in most of the cases. But ForcedFill() will do.

[Kasuha]

Using fragments to fill gaps is a bad idea in most of the cases.

I disagree. If the file is fragmented, there is probably a reason for it (e.g. because the zone was defragmented using defragment(chunksize) command). And in such case it is irrelevant where within the zone individual fragments are placed.
I am not asking for FastFill() to fragment files. I am just asking to have option for it to handle already existing fragments instead of whole files as basic blocks used in the filling process.

But ForcedFill() will do.

Using ForcedFill() is a bad idea in most of the cases because it makes fragmentation worse.

[ScorpionGTfx]

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?

[BloodySword]

No! No! No! Why should it be a benefit if you can not define the behaviour each FileAction session? I don't understand your point...

[ScorpionGTfx]

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

[BloodySword]

Defragment will never Wrap arount, because of it'S concept. It searches a position to move the whole file to and might move files away.

[ScorpionGTfx]

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

[BloodySword]

Yes that's true. But the recognition should be improved a bit.

[Kasuha]

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?

You still need to learn some of MyDefrag's problems.
WrapAround function wraps moved files around files which are unmovable during the defragmentation run which applies generally to any temporary file the system decides to use.
On my computer, trying to optimize a zone using a SortByName command leads to approximately 30% files being marked as fragmented right after they were placed at their position. The first following run of "daily optimization" moves them all twice - once when defragmenting them, once when filling them back. I really don't think it's a good idea to have this happening every daily defragmentation.