Won't You Like a TEST() Command?

[t1470258]

Hi,

If you're a noob like myself in the scripting world of MyDefrag v4 then you may fall into many pitfalls while writing/testing your "new" script and can REALLY MESS with an already optimized drive. I know by sad experiences...

Won't you prefer another Scripting Command like "Test()" likely to be placed under FileActions as the "Last" Command which will only defragment the drive "visually" not "physically" only showing the resulting visual map for user to confirm if the result is acceptable. I believe implementation would be quite easy (maybe just wishfull thinking) since defragmentation will be done mentally (in the RAM, only visually) and would be finished in "seconds" since there won't be actual defragmentation...

If the user/script writer likes this visual result and he/she only removes Test() Command from the script and rerun the script for the previously observed result to take place in the drive...

This is IMHO should have been included by default since MyDefrag has now some kind Scripting Language and every Language has some sort of error tracing/viewing mechanism to assist its user for potential errors BEFORE the error occurs...

Believe me it's hard to trace and rectify the result if you screw in your script (contradictory commands, misplaced statements etc...) and run it on today's LARGE drives. After GBs of data movement and many many minutes you may sadly discover you traded your current drive situation for the worse dreaming for the better...

I also know good fellas here can help if I'm to post my screw-up script. Yet for MyDefrag to be "Autonomous" every user "could" trace back his error without higher supervision by means of Test() easing everyone's life...

Thus I strongly recommend some kind of error catch mechanism should be implemented in the future versions of MyDefrag...

Thanks ;-) ...

[jeroen]

Thanks for sharing your idea, I appreciate it. A dry-run mode has been suggested before and would be useful, and is already on my wishlist. Just to clarify for other people: MyDefrag checks every script before running it and there is absolutely no way that you can damage your disks by making a mistake in a script. The only "bad" thing that can happen is that the disk at the end is not organised the way you want it to be.

[Falcon4]

I'd certainly love to see a dry-run mode as well, but I can see how it would take a lot of work to implement. The entire disk would have to be somehow virtualized so that MyDefrag can properly tell where a moved file would run into another file, what the order of files would be, etc. It's pretty obvious MyDefrag doesn't think very far in advance and most of its actions are "ad-hoc", determined by "what files need to be here" and not much else... so doing a dry-run would be pretty difficult.

But yeah, it would certainly be on my to-want list... relatively low on there, though

[Thaliur]

Well, actually, only the API commands would need to be skipped, and the move commands could just be sent to the graphic representation generator process (I forgot the word I wanted to use while typing...).
It could run pretty fast, since it won't need to actually move files, just analyze the disk, and then process all the commands on the analysis output.

[Falcon4]

That's what I thought at first as well. But then I thought about how MyDefrag locates a gap to move a file into, vacates a gap, etc., and realized how big a task it would be to make these things "virtualized". The graphical display is just a display of what it's thinking on the inside... perhaps it would be able to use the disk map and known file layout to test a "perfect conditions" scenario, but that would still take a lot of work to virtualize the "information gathering" parts of moving a file (such as "is this spot available?"). But maybe Jeroen could confirm/deny that

[jeroen]

But maybe Jeroen could confirm/deny that

Yes, finding gaps is done in real-time, by asking Windows for the actual diskmap for each and every move. It is one of the stumbling blocks (there are more) that makes it difficult to implement a dry-run mode.

[pauljayd]

Yes, but TEST() wouldn't have to show each and every file fragment, just the areas and their attributes where fragments should end up. Maybe in an outline/bullet-point format of some sort?

[kethd]

Yes, I would LOVE to have a feature that would allow running a script in a TEST-SIMULATION mode!  It should be fast and just a "good guess" of about how things will turn out.  Show the map of results.  Also give simulated log reports. Most important is to show where the zones are going to be!

I am very nervous about defragging my main hard drive, and only want to move all the files around once!  Very hard to guess ahead of time exactly how the custom script will work...

[BloodySword]

A simple TEST-Mode would be also great. It only visulizes where the zones are going to be, ignoring the facts that some files are unmovable or new fragments are created during defragmentation. I think implementing this is not a very big task.

Activating the TEST-Mode could be done with adding a TEST() command on the very beginning of the defragmentation process. Log-Calls are then ignored and the script will only be visualized.

The GUI could then show the zone names directly on the disk map.

[kethd]

The simplest version would not even need to make any visual map.  Just quickly sort through all the files and calculate about how many bytes will be put in each zone, write a log file with that table. This would allow planning a good zone layout.