Optimized progress indicator

[BloodySword]

Hello,

again I have to say: GREAT JOB!

So now, I have an Idea. Don't know if this would be a benefit for a big group of users or not, but:
A progress indicator wich will show the overall progress of all zones would be very nice.
The inicator could estimate the time it could be finished as well.
A progress bar in the status bar would be very cool .

Hope you like this idea and I hope it is possible.

[Thaliur]

I think considering the way MyDefrag works this might be very difficult.

If I understood it correctly, MyDefrag scans the disk, buffering that data, then looks for the files zone by zone, and marks each of them. Then it evaluates the requested operation, like sorting by name (or by last change, which I'm using now, because every defragmentation after the first one is much faster), and checks if the files match the required order. If not, it starts giving "move that there" commands to the Windows defrag API, each time waiting for their completion. And that's the main problem I guess. MyDefrag does not know how fast the API is moving the files, and estimating a time based on the completion times of different files probably doesn't work, since mybe not the whole file needs to be moved.

An overall progress bar might work though. MyDefrag could execute all the FileSelect commands in the script first, check for the total file size of everything, or maybe just use the "VolumeUsed" value, although some scripts don't necessarily move all files (I made an "MFT, directories and Boot files" script for my computer, for example).
Then it could just calculate the ratio between the data moved/checked (everything that's green, and the processed contents of the current zone) and that total value.

And maybe this total percentage could be shown as a taskbar progress, like the new Explorer and IE and basically every Windows component displays (those slowly filling taskbar buttons).

I don't know if that would be difficult to implement, but I would expect Microsoft to have built a default interface for that into Windows, as for the jumplists (which, by the way, work really well with MyDefrag).

[BloodySword]

Thanks for your answer. But I think it is not a good idea to do all the file selects before the script starts moving. Our buddies out there, wich might have older hardware and less than 512 MB ram could get problems with big till 127 gb and with many files, if ALL file selects are processed in memory.

But ther's a different way to display the overall process: The Percentage could be divided through the zone count. This is not very accurate but it works .

The time left would be inaccurate anyway, no matter how accurate the overall progress calculation might be. So I think it wouldn't be so silly to do this calculation. We could get a more accurate calculation if we use the experience of the whole defrag process. So after all, when ca. 50% is done, we have values that might be accurate enough to estimate a good time left value.

[Kasuha]

Personally I think it's not difficult to implement but it'd be unreliable, after getting to 10% in 5 minutes the whole rest might take 1 minute or 5 hours, you never know.

And MyDefrag needs to keep a lot of file information in memory - buddies with small memory and big disks have hard time with MyDefrag, it's proven fact. Sometimes it helps to pre-defragment the disk with windows defragger to reduce number of fragments before using MyDefrag.

[jeroen]

A progress indicator wich will show the overall progress of all zones would be very nice.

Thanks for sharing your idea, I appreciate it. I have experimented with progress bars in the past, with an overall counter, and with predictions based on speed, but I have found that the results are unsatisfactory. So I went back to a simple percentage and a zone counter.

[poutnik]

Maybe percentage for whole volume as ratio of total size of processed files / total size of all files ?

[BloodySword]

I think it would be the total size of processed files / total size of all files selected in all zones.

[poutnik]

I think it would be the total size of processed files / total size of all files selected in all zones.

Yes, you are right, not all files need to be selected.

[BloodySword]

But I read in another thread (maybe it was in the bug area of this forum) that the file size is detemited wrongly if the file is compressed or a sparse file. Or am I confusing?

[poutnik]

But I read in another thread (maybe it was in the bug area of this forum) that the file size is detemited wrongly if the file is compressed or a sparse file. Or am I confusing?

Not sure about compressed files.
Reporting sparse file there is double truth - allocated and really occupied space.
E.g. File IS 11 GB big, most reports from most programs show 11 GB, but it occupies just 8000 clusters, i.e 32 MB.
By copying it to FAT32 volume, it would throw error a file on FAT32 cannot be bigger than 4 GB.

Well, we could count total processed clusters versus total selected clusters.

[BloodySword]

Yes that could be the solution. Don't know if it is easy to implement.
I hope jeroen will give a feedback about this.

[jeroen]

Well, we could count total processed clusters versus total selected clusters.

In most cases the MyDefrag percentage is already calculated exactly like that. But it's not useful in all cases. For example during analysis it would make the percentage make a big jump for a single big file, and hardly change at all for a block of thousands of small files.

[poutnik]

In most cases the MyDefrag percentage is already calculated exactly like that. But it's not useful in all cases. For example during analysis it would make the percentage make a big jump for a single big file, and hardly change at all for a block of thousands of small files.

Yes, it is obvious.
Personally I do not miss such feature.
But I am not against features I do not miss.

[Thaliur]

Thanks for your answer. But I think it is not a good idea to do all the file selects before the script starts moving. Our buddies out there, wich might have older hardware and less than 512 MB ram could get problems with big till 127 gb and with many files, if ALL file selects are processed in memory.

I don't think that would need much memory.
The software would just need to create an optimized logical equation (actually, that's not even necessary, it would only speed up things a bit) and then scan all the files, just adding up their sizes (while avoiding duplicate selections of course).
It would be even easier if the "all" filter is used in the scripts (as it is in most), because the program could look for that first, and then skip all the others, pretty much just using "VolumeUsed".
That wouldn't take into account unmoveable files, but there aren't so many usually, so it shouldn't be a problem.