A true full optimize script that will actually make your system faster.

[Falcon4]

Hm, I don't trust any timestamp related functions at all... Windows does wacky file reads and writes that would most certainly end up throwing junk (spacehogs) in the zone specified for "frequently" accessed files. Since there is no filesystem way to ask "what files are frequently accessed", there's really no way to separate frequently accessed files away from the rest of the junk like System Restore and that movie you just watched 2 days ago.

Except for Windows' boot optimize layout.ini file, which I actually trust more than anything else (although I still detest certain portions of it). It does a somewhat decent job of keeping track of recently accessed files, and files necessary for boot. The only flaw in it is that it often throws those very files I want to exclude into the mix, like "that movie you just watched 2 days ago", for some unknown reason.

As for the topic of optimizing registry placement, it seems that the NT user registry (%Userprofile%\ntuser.dat) and the Windows registry (%windir%\system32\config\*) are actually part of the boot optimize layout. I'm trying to confirm that they were actually placed in the appropriate zone on my hard drive, but DiskView (Sysinternals) is sorely outdated and inefficient, and MyDefrag doesn't seem to offer a way to "find a file" in the disk map - something I'd been banging my head against the desk about today, when trying to locate \$mft on a heavily fragmented drive (DiskView took >30 minutes to scan and tell me "nothing at all" when I asked it for $mft). Kinda makes verifying file placement rather difficult

But I definitely think that the boot optimize layout is quite efficient as it is, and couldn't use much more tweaking other than to remove media and archive files from the boolean somehow.

[poutnik]

Hm, I don't trust any timestamp related functions at all... Windows does wacky file reads and writes that would most certainly end up throwing junk (spacehogs) in the zone specified for "frequently" accessed files.

Better is not to trust any ideas supposing they are what they are not. Filebooleans are able to follow any kind of complex logic. They are only as good as you have written them.

When set Vista to use Last access timestamp ( off by default ), I got in JKDefrag 70-75% files as spacehogs - comparing about 40% vith default vista setings.

Since there is no filesystem way to ask "what files are frequently accessed", there's really no way to separate frequently accessed files away from the rest of the junk like System Restore and that movie you just watched 2 days ago.

"I do not know any solution" is not equivalent to "there is no solution".  :-)
Just think how would you separate them yourself, and then say it by script.
Sidenote: AFAIK System restore points are not moveable.[/quote]

Except for Windows' boot optimize layout.ini file, which I actually trust more than anything else (although I still detest certain portions of it). It does a somewhat decent job of keeping track of recently accessed files, and files necessary for boot. The only flaw in it is that it often throws those very files I want to exclude into the mix, like "that movie you just watched 2 days ago", for some unknown reason.

Many files from layout.ini are not accessed for more than 1 week.
Many of them are not accessed even during boot and login.
Many files, otherwise put into spacehogs, are present in layout.ini too.

As for the topic of optimizing registry placement, it seems that the NT user registry (%Userprofile%\ntuser.dat) and the Windows registry (%windir%\system32\config\*) are actually part of the boot optimize layout. I'm trying to confirm that they were actually placed in the appropriate zone on my hard drive,

Try to create test script with empty fileactions, only with fileselections,
and put title command before every fileselect. Use pause command
Then the inspection is much easier.

[Falcon4]

When set Vista to use Last access timestamp ( off by default )...

... Really? Last access is off by default in Vista? o_O Yet another reason that I both HATE Vista, and don't want to rely on Last Access, because it would just screw up the whole system. =\

Sidenote: AFAIK System restore points are not moveable.

In Vista, yes... system restore points are single huge unmovable files. But since the vast majority of the systems I defrag are XP systems, which store thousands of little files (which are movable, thank god), it's definitely best that they aren't included in LastAccess usage

Many files from layout.ini are not accessed for more than 1 week.
Many of them are not accessed even during boot and login.
Many files, otherwise put into spacehogs, are present in layout.ini too.

Well... the space used for Boot Optimize is so small compared to the rest of the drive, I think it does a "good enough" job... it's almost guaranteed that it's including all the frequently accessed files for startup, so I can't complain

Try to create test script with empty fileactions, only with fileselections,
and put title command before every fileselect. Use pause command
Then the inspection is much easier.

That's an extremely useful idea! I think I'll make a script that mirrors my FullOptimize script that does just that. Thanks for the tip!!

[poutnik]

... Really? Last access is off by default in Vista? o_O Yet another reason that I both HATE Vista, and don't want to rely on Last Access, because it would just screw up the whole system. =\

It does not screw up the system, unless used inproperly. If no use for you now, then not yet able to get benefit from that.  Setting it on is matter of one simple command.

Code:

fsutil behavior set disablelastaccess 0

In Vista, yes... system restore points are single huge unmovable files. But since the vast majority of the systems I defrag are XP systems, which store thousands of little files (which are movable, thank god), it's definitely best that they aren't included in LastAccess usage

I think this code is not complicated:

Code:

lastaccess("x days ago","") 
and size(0,x)
and not  ( 
    fullpath ("restore points path\*") or   fullpath("my favorite multimedia\*") 
    )

also  worth to try is

Code:

ImportListFromBootOptimize()      and lastaccess("x days ago","")  and size(0,x)

Well... the space used for Boot Optimize is so small compared to the rest of the drive, I think it does a "good enough" job... it's almost guaranteed that it's including all the frequently accessed files for startup, so I can't complain

Well, unfiltered it can have up to 4 GB...

[jeroen]

MyDefrag doesn't seem to offer a way to "find a file" in the disk map

Try this script, it will highlight the files specified on the commandline:

Code:

Title('Highlight')
Description('Highlight the specified files')

VolumeSelect
  All
  /*VOLUMES*/
VolumeActions

  /* Analyze the disk and colorize everything in the default colors. */
  FileSelect
    not(all)
  FileActions
    Defragment()
  FileEnd

  /* Change the palette so that the next selected items will be colorized
     in bright cyan. */
  SetPalette(
    unfragmented=0,255,255
    fragmented=0,255,255
    )

  /* Select the specified files and pause, so that the user can inspect
     the files on the diskmap. */
  FileSelect
    All
    /*EXCLUDE*/
  FileActions
    Pause("")
  FileEnd

VolumeEnd

[Falcon4]

Neato! I made a script file out of that, then wrote a quickie batch file that allows me to drag-and-drop a file onto the batch file and have MyDefrag "show me" where it's at in the map. That could definitely come in handy! Also shows how powerful MyDefrag's scripting is...

I also followed poutnik's suggestion above, regarding using pause() and Title() as the FileActions, and made a "FullAnalyze" script that shows the files in each of the zones of the script. Also found that SetBeginOfZone() actually does start moving files (... from what point?) so I had to take those out for the analyze script... XD

Definitely some awesome script tools we've got here...

[Falcon4]

Updated after all these months! Now compatible with the latest version of MyDefrag (pulled from my working copy of 4.2.0 Beta). I've been updating it continuously over the months but the lack of interest in this topic kinda made me not care to update it. But it desperately needed an update anyway (and I think it's worth the effort), so here it is.

Too many changes to list... nearly re-wrote the whole original post. It works quite well if I may say! It's the only script I ever use MyDefrag with, for obvious reasons 

edit: Changed the topic title, since I can pretty much 100% vouch for its performance since I use it on a daily basis on a huge number of computers... 

[Arhu]

Hey. I've been looking at MyDefrag for a day now and I'm preparing to use it with some custom scripts.

This one looks very good for my Win7 system partition. Some questions though:

In the OP you write that this is a script that should be run only rarely (monthly or so), in your last post you write that you are using it daily. Which one is it? Judging by the Defrag() and FastFill() methods you use in your script, this looks like a daily script. Would it make sense for me to create a monthly version that uses SortByName like the default MyDefrag Monthly script and run it once?

I haven't used any scripts yet by the way, I'm still making some adjustments to the layout logic of my partitions.

[Falcon4]

I say I use it daily as in, I use it on different systems daily. I'd say I've used this script on over 100 systems so far, at least once a day (likely closer to 200). But I only use it once on a system, then delete it. It shouldn't need to be run again on that system for quite some time. Files don't just "move" on their own and system files aren't continuously updated (except the MFT, registry, and a few others). So you should just have to use it once and forget it

[grahamcopley]

Updated after all these months! Now compatible with the latest version of MyDefrag ..., so here it is.

Is the link to the script missing?

[Darlis]

You can find the script in the first post.

[rich]

How about the recently updated script? Thanks! Great software and great work everyone.

Rich

[poutnik]

I also followed poutnik's suggestion above, regarding using pause() and Title() as the FileActions, and made a "FullAnalyze" script that shows the files in each of the zones of the script.

If you included timestamps, you would realize,
how many of "frequently accessed" files are not accessed at all.

Not wise usage of both timestamps and paths can be misleading by similar way.

You are true in that recent access does not mean frequent access.
But you need to focus the opposite: no recent access means no frequent access.

For your path based zones would do better job
e.g. "your selection" and lastaccess(1 month ago, )

Similar, many user files, accessed last month, and restricted by sizes and types,
according to access patterns, could and should be hold at fast area.

Make your script to think little more.
Fileboolean syntax allows it to be almost as clever as you are.

( note to others - not applicable to Vista unless having activated last access timestamps )

[Falcon4]

How about the recently updated script? Thanks! Great software and great work everyone.

Rich

I always update the original post since it's the post people will look at first. No use keeping old information up on the first post

As far as using time stamps, I simply don't use them at all since they are just too unreliable. Sure, I can (and will) use more zones and filebooleans to make it a bit smarter, but that'll have to come when the need arises.

[poutnik]

As far as using time stamps, I simply don't use them at all since they are just too unreliable. Sure, I can (and will) use more zones and filebooleans to make it a bit smarter, but that'll have to come when the need arises.

Time stamps themselves are not unreliable.
What is unreliable is interpretation how we use them.

I did not advice to create more zones at all.   

I have just adviced not to keep files, not accessed for months, at fast disk areas,
and files, accessed often, at slow disk areas.
Otherwise the disk head will be fiddling around the whole disk.