Oh. So it is expected to be linear? Ok, maybe in the future...

And the two-scripts approach, I tried that. Somehow I wasn't even able to move the files in the end even with example script. Does it assume the space in the end should be free? If all other files are excluded, they are marked unmovable, aren't they? Problem is, total free space on this volume is less than size of the files I want to put in the end. So no luck there...
Actually that's my biggest problem with MyDefrag - not being able to put files in the end of disk easily. Too bad it's free and I can't complain 

...In the end I finally did what I wanted. One script, but it took a few passes. The original MakeGap(to-the-near-end,DoNotVacate) <myfiles> SortByName(Ascending) MakeGap(0) idea worked. I just had to manually calculate appropriate beginning of a zone + some headroom. I haven't tried but I guess it wouldn't work without headroom in the end of disk...
The weird thing is - the script would move out the already sorted files and then put them right back in the same place they were even after complete defragmentation.
Also, as it took more than 1 pass (which really shouldn't be the case for SortBy placement), this defeats the original "move these files out of the way for easier defragmenting the rest" idea as now it actually took even more time. So I really hope for a proper way to do it in the future. Cheers.

I'm not sure if it's impossible with current scripting system or am I missing something. Nothing I try seem to work. I need to put some files at the end of disk, but they shouldn't be in the last zone (in the last zone it works quite ok with AddGap(MaxNextZoneBegin) as I've done on smaller volumes, but those files would considerably slow processing of all the zones they would be not included to... this disk is big. That's exactly why I need to move them in the end - to be out of the way.)

My best bet was
  MakeGap(VolumeSize, DoNotVacate)
  FileSelect
    <special files boolean>
  FileActions
    SortByName(Ascending)
  FileEnd
Followed by quite magical MakeGap(0) (as used in default scripts after MFT/directories).
But it just selects those files and immediately marks them done/green and skips to the next zone.
And MakeGap(MaxNextZoneBegin, DoNotVacate) doesn't help either. It seem to include not just the next zone, but all the zones left to process while calculating maximum gap. So files start to get moved to nowhere near the end... Or maybe there's a bug? I've read there's some bugs in AddGap? Should this work in the next release? Or scripts are supposed to be strictly linear beginning-to-end and MFT/directories are just a special case and treated specifically?

Small question. In ChunkSize() example there is a "100" number used:
Defragment(ChunkSize(100))
But as I understand, NUMBER 100 is 100 bytes? Or ChunkSize defaults to Megabytes?
Or it's just example that wasn't updated when NUMBER syntax changed?

That is worth incorporating in default scripts IMHO (using layout.ini for datafiles on non-system disks is pretty useless, it usually harms more than helps). Except of course there should be proper %SYSVOL% used. Can environment variables be used in scripts?

Have you started MyDefrag from a commandprompt window? Was the current working directory the ""C:\Program Files\MyDefrag v4.0b4\" directory? I think maybe the crash report is not generated because it cannot find the "MyDefrag.pdb" and/or "dbghelp.dll" files from that folder.

MyDefrag was started from Far, while in "c:\program files\mydefrag\scripts". Though .myd scripts are started from windows accociations, so I'm not entirely sure what current dir for associated application would be in that case. Still, it's probably "scripts". But why it could be a problem, aren't those dlls should be found from where .exe was started from?

BTW, after some more defrag/optimizations MyDefrag no longer crashes on that volume (and works pretty nicely, even with my first crudely-constructed custom script ). So it's definitely (was) data-related problem, not environmental.

P.S. I've checked with ProcessExplorer. Yes, current directory is "C:\Program Files\MyDefrag\Scripts\" when started as described. And when started from StartMenu-Run ("scriptname" arguments), current dir is also "scripts".

I think I have a similar problem. MyDefrag b4 crashes on one of my disks (logs attached).
I'm running "AnalyzeOnly.MyD e:" with default scripts.
All other volumes analyzed ok. On my E: disk, however, last I see is 99.8%, and then window closes. It's ~85GB NTFS partition with ~270k files. It was heavily fragmented, but not anymore. Also of note, I just deleted about 20-30k of ADS (alternate data streams) from that partition. Though sadly I can't say if that is relevant, 'cos I didn't try MyDefrag on it before. JkDefrag works on it, albeit slowly (speed is the reason I decided to try MyDefrag, JkDefrag seems really slow when there's a lot of small gaps present...)