Even running highlight script is faster (with the added positive of filebooleans).

HDView needs about the same analysis time as MyDefrag. And you have to restart MyDefrag every time you want to highlight other files.

Ok, that time it might have been a fluke. I remember hdview taking like 3-5 minutes to analyze my system volume. Now I timed it and it is within 10-20% the same as MyDefrag (more dependent on disk caching though).

and file flashes for only a second? And if the file is not in the current view highlight does nothing.

Nope, the file(s) stay highlighted, even those currently not visible in the zoomable view.
Maybe you used an older version of HDView?

Hmm, indeed I was. But aside from fragmentation list, I can see no difference. I'm not sure what was happening when I tried to use it before, now I see highlighting. Except there's still a problem: current view doesn't move to where found file is. If file is small, it's not seen on the whole map on the right. So I have to find it with another command, double-click to see LCN, remember LCN, close that window and manually scroll till I find that LCNs region. Am I missing something again?

And still, wouldn't it be great to test FileBooleans without reanalyzing the disk each time?...

HDView is the tool you need.

That is exactly the one I was talking about with words like "slow" and "unwieldy"
Even running highlight script is faster (with the added positive of filebooleans).
Plus file search in hdview works weird. Search only lists files, from there I can click to see LCNs. But to highlight a file I need to use another command, and file flashes for only a second? And if the file is not in the current view highlight does nothing. Either I do not understand how to use it, or it's usability is very, very poor indeed.

Have you tried it yet? My guess it would move out the Zone 6 up, but won't be able to defragment it there - as there will be no free space above ZoneBegin.

As much as I want (sometimes:) to have perfectly sorted zone at the end of disk, currently MyDefrag options for it are limited. Maybe using something like MakeGap(<calculate shift here>, DoNotVacate) and SortBy() in the last zone should work, but I haven't tried it. I still can't get to remember what operations do moveuptozone and what don't.

I've used plain MoveToEndOfDisk() before, but files you want to put there tend to be large, and the end always ends up with a lot of big gaps. What's worse, as free space dwindles (as it does), MoveToEndOfDisk() spends a lot of time moving huge files from the middle to... slightly farther middle (because the end is littered with gaps and small files). I'm beginning to think that I am not as much want to have these files at the end as at the side of the disk - to remove them from active zones where file creation and fragmentation happens. So maybe putting them in the very first zone might be a better idea (that's not a general suggestion though, obviously, and certainly not for system volumes).

When processing any disk with SortBy()s, which are part of Monthly scripts, there is a chance of temporarily creating much more fragmentation while a lot of files are being moved out to sort the files. This is especially noticeable if free space is low (if free space is plenty, files moving out do not get fragmented as much). This temporary fragmentation should go away when fragmentation is complete, obviously. However, if at the time of increased fragmentation some unfortunate disk activity happens, which locks those temporarily fragmented files - that's when it can get ugly.

1. Remember about wrap-around fragmentation (already mentioned before, but worth repeating).
2. Directories on FAT - extra unmovables (same). Upgrade to NTFS if possible.
3. Before defragmenting with Monthly stop as much disk activity as possible, that is, quit all background programs, disable antivirus, turn off excessive logging (for example firewall logs on a busy network can generate a lot of writes - small, but frequent), temporarily stop Windows services that can decide to write disk (like indexing, backup, autoupdates).
4. Free up as much free space as possible (delete restore points, browser caches, clear temp directories, etc.)

That would be a very useful feature for debugging your scripts. I had to create more than one script just to highlight specific file(s) on a disk map for that.
Other tools probably exist that can do that ... in fact, I just found one installed (and forgotten about). But it's slow and unwieldy.
The whole point here would be an option to quickly check various filebooleans without reloading all disk data structures (which can be quite slow if disk has a huge number of files). Otherwise a simple highlight script would do. Or maybe not. A small file could be hard to find without the blinking option.

Actually the answer to you question is in the manual, but I can see how it can be a little confusing.
ExcludeFiles() is a setting. It doesn't actually says it doesn't work inside VolumeSelect, it says it must be used outside. To be applicable to the volume you're about to select and process with VolumeSelect, setting must be defined - so it goes before VolumeSelect.

Another way to skip big files without the chance of them being fragmented and splattered all over the disk is to use this zone first:

# skipping big defragmented files
  SetFileColor(Size(4GB,0) and Fragmented(no),All,10,110,10) #also color them dark green
  FileSelect
    Size(4GB,0) and Fragmented(no)
  FileActions
  FileEnd
  MakeGap(0)

It selects all big (>4GB, but obviously that fileboolean should be tweaked to your needs) defragmented files - and does nothing with them, therefore these files would be skipped by all future FileSelects. This zone has to be first, as pointer has to be reset with MakeGap(0).


Answer to you second question is in the beginning of the automatic script itself:
# MyDefrag v4.0 default script: Daily
#
# Fast defragment and optimize all the disks. This script is designed for running
# automatically, it always processes all disks and ignores selections from the
# commandline and the script chooser, and it will automatically exit when finished.
# This script is used by the screensaver and by the Daily scheduled task that is
# created by the MyDefrag installer.
#
# The script does the same tasks as the 'System Disk Daily' script for the C: disk,
# and then the same tasks as the 'Data Disk Daily' script for all the other disks.
# For more information see those scripts.

Best approach time-wise here would be to move most data to another volume, defragment the rest and move files back. Obviously it requires some downtime, but overall it would be a number of magnitude(s) times faster.

Yes, it is possible. You need to make a modified script and use
WhenFinished(Shutdown)
setting in it.
http://www.mydefrag.com/Settings-WhenFinished.html

I've used
    AddGap(RoundUp(ZoneEnd,50GB))
for similar reasons.
The obvious downside is that disk layout will be screwed up if the zone gets larger than 50GB.

meanwhile spam-bots started to advertise math tutoring, lol

How about a file flag next to .exe? Small .ini with a customizable path might be even better, but probably a bit of overkill. But file flags are already somewhat frequently used, mostly for portable modes, but sometimes for storing in %APPDATA% as well, for example foobar2000 looks for file "user_profiles_enabled".

Edit: Hmm, wait. MyDefrag doesn't really need multi-user profiles, all users share the same disks.
There is %ALLUSERSPROFILE%, or [Shared] My Documents. I'm not sure what's most correct here...

1. You may ignore rims, it's just a spam bot.
2. Yellow color doesn't indicate unmovable files, red does. Yellow is fragmented files. Just let the script finish, yellow should be gone. And I don't see much reds on your screenshot.

3. Put MFT/directories between zone 1 and 2.

Actually it's an interesting thing, placing MFT and dirs in Nth zone, without MakeGap(0) trick. I've tried it and it seems to work ok, but I'm still hesitant to use it regularly, as I know too well not everything that seems possible with those scripts actually works as one might expect.

You have a point there with the changing directories zone, but considering that the files in this case don't change at all, there is no point in running the script several times.

These files do not, others might.

The best place would be 2 or 3 GB into the volume.

That would result in pointless data moves on each run if combined size of ELITE and PCHD is greater than 2GB (which I guess it is). Problem is directories always change size on an active disk. Putting them inside the zone which is SortBy-ed is a bad idea in this case (the point is to place those files and never move them again). There are two options:
1. Put MFT/directories at the beginning and reserve some space for growing directories.
2. Put MFT/directories after the sorted zones.
Both are not ideal from MFT placement perspective, sadly. There's also a variant of putting MFT inside the sorted zone (allocating more than default data disk script 1% MFT reserved space might be a good idea here) and directories after the zone, but I guess that might be even worse performance-wise.

Personally I have a similar case and so far Option 1 works for me. In fact, it's currently in default data disk script (as I understand Jeroen decided to move MFT further for data disks too after certain discussion, but for me inability to reserve some space after directories in this case outweighs MFT placing benefits...)

Q1: What are the usual tags that cause the API to refuse?

Is there typical registry entry?  A lot of my unmovable dirs can be deleted with no complaint as to file in use, or other similar distraint.  The programs that own the files or dirs are not running.  The only thing that I can find that is possibly "tagging" them is a registry key under microsoft installer ...

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Installer\Folders]

Can a registry key be set so as to "tag" a file or dir so that the defrag API will return a refusal?

It has nothing to do with registry. There are various file locks in Windows. Certain types of these locks make usual files unmovable while they are locked.
Stopping the program doesn't always releases all used files. For example, some DLLs might still be locked by the system.

Q3: Is the standard MS defrag API just a lite version of the full version API used by Diskeeper?  Would it make any difference to have MyDefrag use the full version API of Diskeeper?  Has anyone done a file compare?

No no no. Built-in defrag (which was based on simplified Diskeeper, yes), commercial Diskeeper, almost all other defragmenters for Win2K/XP and up use Microsoft Defragmentation API.
As I understand, the API itself is pretty simple, it's just a bunch of control codes, mostly FSCTL_GET_VOLUME_BITMAP, FSCTL_GET_RETRIEVAL_POINTERS and FSCTL_MOVE_FILE (there's basic info at http://msdn.microsoft.com/en-us/library/aa363911(v=vs.85).aspx). What you can do with them - that's defragmenter software. And as we all know, it can be quite different.