Thanks for the MoveToEndOfDisk

[isgdre]

The bug in the 3.36 has been kind of annoying but with the addition of MoveToEndOfDisk it looks like I'll finally be able to move to the 4.x series. 

Thanks for the great work.

[jeroen]

MoveToEndOfDisk is a bit slow, especially for small files. Best to use for big files only. The next release will have an improvement, but it will never be very fast.

[isgdre]

I only use it to get Large files (old backups and such) that will likely never be accessed again unless the sky really starts falling. 

In your "Improvements" would it be possable to sort the files as they are moved and fill in around unmovable files.

thanks.

[jeroen]

In your "Improvements" would it be possable to sort the files as they are moved and fill in around unmovable files.

Perhaps in the future. Gaps at the end of the disk are filled, but only by files that are before the gap and smaller than the gap. I don't think usually there are many unmovable files at the end of the disk. Also I think the end of the disk is a bit like a garbage dump anyway, for unused files and such, no use in wasting a lot of time on it.

[Cushy]

Was there a need for MoveToEndOfDisk()? Why not teach Defragment() & FastFill() to use all the available free space all the time?

[jeroen]

Was there a need for MoveToEndOfDisk()?

Not in my opinion, no. But a lot of people asked for it.

Why not teach Defragment() & FastFill() to use all the available free space all the time?

I don't understand, what do you mean?

[poutnik]

Was there a need for MoveToEndOfDisk()?

Not in my opinion, no. But a lot of people asked for it.

I think if a disk is not almost empty,
and if there are many big files without fast transfer requirement,
and if there is need to have free area for speed disk writing,

then I would say it can be handy.

Edit: By other words - optimizing of placement of files that do not need it
can lead at some circumstances to wasting of fast disk areas.

Free space can be taken as a special kind of file.
If it is accessed and written much more often than some normal files, it deselves better placement than those files.
Sure, all depends on intensity and size of free space usage.

[Cushy]

Why not teach Defragment() & FastFill() to use all the available free space all the time?

I don't understand, what do you mean?

It seemed to me that Defragment() & FastFill() can use for their operations only that free space that is located after the zone currently being processed by them. And because of that if the zone is located at the beginning of the disk it gets neatly defragmented & fastfilled but when the zone is located right at the end of the disk some files in that zone are left fragmented.
For example the script

Code:

FileSelect
FullPath("E:\Program Files","*")
FileActions
Defragment()
FastFill(WithShuffling)
FileEnd

MakeGap(MaxNextZoneBegin)

FileSelect
All
FileActions
Defragment()
FastFill(WithShuffling)
FileEnd

produces the attached result (the beginning of the disk is on top).
I think that the reasonable action for Defragment() function should be to always use all the available free space even if this free space is located before the zone being processed. And for the FastFill() it should be:
1. For all the files from the current zone located after the beginning of the current zone use the existing FastFill() algorithm (allowing to use the free space located before the current zone for the files temporarily moved there when using "WithShuffling").
2. For the remaining files from the current zone (those located before the beginning of the current zone) use the algorithm from MoveToEndOfDisk() to move these files to the end of the current zone.

[jeroen]

It seemed to me that Defragment() & FastFill() can use for their operations only that free space that is located after the zone currently being processed by them.

Ah, I see what you mean now. Yes, if MyDefrag used free space before the beginning of a zone then actions like Defragment and FastFill could be used at the end of the disk, and there would not have been a need for a separate MoveToEndOfDisk action. But that would have meant a lot of changes to a lot of code in MyDefrag, a lot of work. Not just Defragment and FastFill. Perhaps in the future.

[CestMoi]

1st: My(JK)Defrag is wirklich ausgezeichnet!       especially for the OS drive (or partition)!

2nd: For data drives (partitions), "Move to End of Disk" is invaluable for all non-OS partitions with "never-used" files taking up >25% of the disk space.  Every 6 months I usually move "almost dead" files (back-ups, etc.) to the EoD of data drives/partitions in all my desk, lap & server units. 

RESULT: phenomenal speed increase accessing the active files.  Huge 20-40% speed increase occurs if the partition has >50% "never-used" files and is >60% full.   

3rd: I hope that someday JK grows to love Move to EoD for such mostly-inactive data partitions!  I know he could write a script to optimize such data partitions MUCH better than the miserable ones I have cobbled together.   

[jeroen]

RESULT: phenomenal speed increase accessing the active files.

I agree that moving the spacehogs to the end of the disk will make the regular files faster. But this will leave a huge empty gap between the regular files and the spacehogs. In my opinion this is a waste of perfectly good harddisk space and makes the spacehogs slower than they need to be. This is why the standard MyDefrag scripts do not move the spacehogs to the end of the disk, but to a separate zone after the regular files.

[poutnik]

I agree that moving the spacehogs to the end of the disk will make the regular files faster. But this will leave a huge empty gap between the regular files and the spacehogs. In my opinion this is a waste of perfectly good harddisk space and makes the spacehogs slower than they need to be. This is why the standard MyDefrag scripts do not move the spacehogs to the end of the disk, but to a separate zone after the regular files.

If considering free space as a special kind of file, all depends on relative importance of free space and spacehogs in particular partition scenario.
It can happen then significant portion of free-space-file is accessed often and need fast access.

I think in example script folder there can be stored little more sample scripts for special scenarios,
as an initial guide for lets say intermediate advanced users, who would like starting to use their own script.

[BloodySword]

RESULT: phenomenal speed increase accessing the active files.

I agree that moving the spacehogs to the end of the disk will make the regular files faster. But this will leave a huge empty gap between the regular files and the spacehogs. In my opinion this is a waste of perfectly good harddisk space and makes the spacehogs slower than they need to be. This is why the standard MyDefrag scripts do not move the spacehogs to the end of the disk, but to a separate zone after the regular files.

Jeroen, on system drives I agree with that. But if you have any external drive or some partitions without system files, moving spacehogs to the end is a good idea.

[jeroen]

If considering free space as a special kind of file, all depends on relative importance of free space and spacehogs in particular partition scenario.
It can happen then significant portion of free-space-file is accessed often and need fast access.

I agree that it all depends, and I agree that free space is important for temporary files. That's why the standard scripts create a couple of gaps. I think these gaps are more than enough for the vast majority of the computers, so I do not see a need for moving the spacehogs to the end of the disk. I would agree with you if all spacehogs files were totally unused files, but files like that should be deleted or moved to offline storage. But many spacehog files are used, some of them by Windows itself, and should therefore not be placed at the very end of the disk if there is perfectly good, unused, and faster diskspace available.

[jeroen]

Jeroen, on system drives I agree with that. But if you have any external drive or some partitions without system files, moving spacehogs to the end is a good idea.

Well, MyDefrag can be customized, so if that is what you want then you can make it so. Personally I think it is a bad idea. I want all my files on the fastest part of the disk, especially on slow external disks, even if they only contain spacehogs such as movies.