Dry Run instead of Analyze Only

[Kasuha]

My idea is to introduce a "dry run" option to starting any script with MyDefrag. Any script can be either started normally or in this mode, in which:
- no files are moved
- contents of MyDefrag.dat is accepted without trying to move anything
- for each file MyDefrag determines to which zone it belongs
- layout is displayed and it is possible to select zone and its files get highlighted
- at the end of dry run, the user has option to start the script normally or exit

So in general it is about determining zone number for each file and then allowing the user to highlight files by groups in which they will be put together by this script.

It is possible to reach similar result by editing the script, removing all file moving and gap vacation commands and putting Pause() command after each zone but it only allows to list forward and once. The point is to have this option available to any script without need to edit it.

Eventually this mode may use different coloring for zones using SortBy commands, suggesting the sorting of files by e.g. brightness - this way the user can observe how much unsorted the zone is.

[jeroen]

Thanks for sharing your idea, I appreciate it. It's already on my wishlist.

[Araigadai]

I knew I wasn't the only one to think of this.

Instead of thinking of "dry run" though, I was thinking "test fit".

Seems simple enough as it only only needs to be based on File booleans (zones) and not actual fileactions.

Maybe just a FileAction command like "DryRun()" or "TestFit()" instead of an addition to the UI. Once all the gaps and FileBooleans are debugged the script can be re-edited and the user can insert the actual FileActions.

Example:

VolumeSelect
  Name("C:")

VolumeActions
MakeGap(10GB, DONOTVACATE)
FileSelect
  DirectoryName("Windows")
FileActions
  DryRun()                           //comment or delete this line after testing
// Sortbyname(Ascending)     //uncomment this line after testing
FileEnd

MakeGap(40GB, DONOTVACATE)
FileSelect
  All
FileActions
  DryRun()                           //comment or delete this line after testing
// Sortbyname(Ascending)     //uncomment this line after testing
FileEnd

VolumeEnd

Any update on the implementation of this feature?

DOH! Sorry, It looks like I'm replying to a year old post. It was only a couple of pages down. 

PS: it really sucks when your 400G of files don't end up where you want them because you messed up a formula or forgot a Makegap()   

[jeroen]

What would you like your DryRun() command to actually do? If nothing then we don't need something like that, you can execute your script as you show it but without the DryRun() commands. If you want your command to do something then what should it do? There are many FileActions commands, some move files up, others down, sort, fill gaps, etc. etc.

[Araigadai]

What would you like your DryRun() command to actually do? If nothing then we don't need something like that, you can execute your script as you show it but without the DryRun() commands.

Except, actually moving the files can take hours...

If you want your command to do something then what should it do? There are many FileActions commands, some move files up, others down, sort, fill gaps, etc. etc.

I'm not asking for anything more than the OP was. Just a different implementation.

My idea was to just draw a block on the diskmap as a perfect case, like one of the sort commands. I don't consider a FastFill() a perfect case since it can leave tiny gaps all over the place. But because of that, I can see a FileAction command isn't going to be the right thing, but some kind of global setting might be. A command to put before the volume select maybe...

I do kinda like the OP's method. Ticking a check mark box beats editing a script. Editing a script is a good way to introduce errors. MyDefrag is good on finding syntax errors in scripts, but not showing what the results of the script are until the script has run. ( Like programming, No errors on compile, let's run the program. CRASH! )

The DryRun() command as a global setting does have the ability to be used by script writing programs/frontends. It would set a flag, so commands would do everything but call the routines to move the files.

It also occurred to me this command might not be amenable to the way MyDefrag is written. It all depends on where the map comes from, I suppose.

Are you basing the map on data read from the disk? ( move file, read map from disk, move file, read...) or are you keeping track of it with the program? ( Movefile, update map, move file, update... ) I guess it could be some other overly complicated method, too, though.

I don't think MyDefrag is keeping track of and drawing the map itself, whatever method is used. Otherwise, it seems it would be a simple thing to not move the files and just draw the map.

If it's not that simple, never mind.

However it's done, the goal is to test run the script in minutes instead of hours.

Thanks for listening.

[jeroen]

I can see a FileAction command isn't going to be the right thing, but some kind of global setting might be. A command to put before the volume select maybe...

Yes, a global setting that will simply block fileactions from actually moving files would be possible. You can already do that yourself, though, by simply commenting-out all the fileactions in your script. MyDefrag will run through the script, select files and stuff, but not actually move files.

or are you keeping track of it with the program? ( Movefile, update map, move file, update... )

MyDefrag checks the actual position of a file after every move.