Well, the MyDefrag GUI is improving (still would like MyDefrag to "ask me" what it wants to do if I start it with no parameters, give me the ability to open a script or select volumes, without having to create a batch file or use the command line), but...

What do the disk map colors mean? Yellow is fragmented, light-ish-red is unmovable, but what is the difference between dark/light blues? I sort of think it relates to zones, but I see some behavior that makes no sense for that...

Processed or unprocessed, maybe?

I encountered this bug as well, DirectoryName selects zero files - it goes straight from "Starting FileBoolean" to "Finished FileBoolean" without anything I can really see getting done. I placed a "Pause("")" right after the FileSelect/DirectoryName/FileActions/FileEnd, and it flew right into that wall without putting any files in the zone.

Here's the portion of my script:
FileSelect
 DirectoryName("Program Files")
FileActions
 Defragment()
 FastFill()
FileEnd

And let me tell ya, having to go into WinHex and take out those first two bytes is a bit tedious!

But dang if this program isn't a dream come true. I don't mean to make it look like I've got nothing but problems! Being able to even consider doing this is _great_!!

edit: I worked around this by using "FullPath("?:\Program Files\*")" which is also a bit more accurate (what happens if I have a folder on the desktop called Program Files?). That seems to work!

[breaks up]

Maybe this will help provide some insight into its behavior. Here's the log for moving $mft (and trying to defragment it)...

Code:

19:42:47     Starting FileBoolean.
19:42:47     Finished FileBoolean.
19:42:47     Starting FileActions.
19:42:47     Calculating the end of the zone.
19:42:47       Number of clusters in selected items: 28960
19:42:47       Iteration 1: 2 unmovable clusters between 0 and 28960, ZoneEnd = 28962
19:42:47       Iteration 2: 2 unmovable clusters between 0 and 28962, ZoneEnd = 28962
19:42:47       New ZoneEnd = 28962
19:42:47     Starting to sort by Name.
19:42:47     Starting to create sorted list.
19:42:47     Finished creating sorted list.
19:42:47       I want to place Inode=0 ('C:\$MFT') at Lcn=0, 28960 clusters.
19:42:47         Testing if Inode=0 ('C:\$MFT') is already at LCN=0
19:42:47           Skipping unmovable data at LCN=0, LCN is now 2
19:42:47           Item at LCN=2 is movable.
19:42:47           No, it is at LCN=38135.
19:42:47         I need 28960 free clusters at LCN=0, calculating until where I have to vacate.
19:42:47           There are 28955 empty clusters plus 3 movable clusters between 0 and 28960.
19:42:47           Looking for the first gap after Lcn=28960.
19:42:47             Gap found: Lcn=28960, Size=9175
19:42:48           There are 9175 empty clusters plus 0 movable clusters between 28960 and 38135.
19:42:48           Status: vacating from 0 to 38135 will result in 38133 free clusters.
19:42:48           Result: I have to vacate until 38135.
19:42:48           Vacating movable items between LCN=0 and 38135.
19:42:48             I want to vacate Inode=1308 ('C:\WINDOWS\bootstat.dat') at Lcn=2, 1 clusters.
19:42:48             Looking for the first gap of 1 clusters after Lcn=38135, or the largest gap.
19:42:48               Gap found: Lcn=107414, Size=33412
19:42:48             Forcing Inode=1308 ('C:\WINDOWS\bootstat.dat') to gaps starting at LCN=107414
19:42:48               Moving Inode=1308 ('C:\WINDOWS\bootstat.dat')
19:42:48                 Moving 1 clusters to Lcn=107414.
19:42:48                 API is moving 1 clusters at offset=0 to Lcn=107414.
19:42:48                 Getting cluster bitmap:
19:42:48                   Extent: Lcn=107414, Vcn=0, NextVcn=1
19:42:48                 Testing fragmentation from 0 to 1 (1 clusters).
19:42:48                   No, not fragmented
19:42:48             I want to vacate Inode=5 ('C:\.') at Lcn=1848, 2 clusters.
19:42:48             Forcing Inode=5 ('C:\.') to gaps starting at LCN=107415
19:42:48               Moving Inode=5 ('C:\.')
19:42:48                 Could not open: [123] The filename, directory name, or volume label syntax is incorrect.
19:42:48                 Changing the item into 'not movable'.
19:42:48                 Calculating the end of the zone.
19:42:48                   Number of clusters in selected items: 28960
19:42:48                   Iteration 1: 4 unmovable clusters between 0 and 28960, ZoneEnd = 28964
19:42:48                   Iteration 2: 4 unmovable clusters between 0 and 28964, ZoneEnd = 28964
19:42:48                   New ZoneEnd = 28964
19:42:48             Finished vacating.
19:42:48         Looking for the first gap after Lcn=0.
19:42:48           Gap found: Lcn=2, Size=1846
19:42:48         Forcing Inode=0 ('C:\$MFT') to gaps starting at LCN=2
19:42:48           Moving Inode=0 ('C:\$MFT')
19:42:48             Moving 1846 clusters to Lcn=2.
19:42:48             API is moving 1846 clusters at offset=4 to Lcn=2.
19:42:48             Getting cluster bitmap:
19:42:48               Extent: Lcn=786432, Vcn=0, NextVcn=4
19:42:48               Extent: Lcn=2, Vcn=4, NextVcn=1850
19:42:48               Extent: Lcn=39981, Vcn=1850, NextVcn=28964
19:42:48               Hiding the first 4 clusters of: C:\$MFT
19:42:48                 Extent: Lcn=2, Vcn=0, NextVcn=1846
19:42:48                 Extent: Lcn=39981, Vcn=1846, NextVcn=28960
19:42:48             Testing fragmentation from 0 to 1846 (1846 clusters).
19:42:48               No, not fragmented
19:42:48           Item partially placed, 27114 clusters more to do
19:42:48           Looking for the first gap after Lcn=1848.
19:42:48             Gap found: Lcn=1850, Size=38131
19:42:48           Moving Inode=0 ('C:\$MFT')
19:42:48             Moving 27114 clusters at offset=1846 to Lcn=1850.
19:42:48             API is moving 27114 clusters at offset=1850 to Lcn=1850.
19:42:53             Getting cluster bitmap:
19:42:53               Extent: Lcn=786432, Vcn=0, NextVcn=4
19:42:53               Extent: Lcn=2, Vcn=4, NextVcn=1850
19:42:53               Extent: Lcn=1850, Vcn=1850, NextVcn=28964
19:42:53               Hiding the first 4 clusters of: C:\$MFT
19:42:53                 Extent: Lcn=2, Vcn=0, NextVcn=1846
19:42:53                 Extent: Lcn=1850, Vcn=1846, NextVcn=28960
19:42:53             Testing fragmentation from 1846 to 28960 (27114 clusters).
19:42:53               No, not fragmented
19:42:53         Testing if Inode=0 ('C:\$MFT') is already at LCN=0
19:42:53           Skipping unmovable data at LCN=0, LCN is now 2
19:42:53           Skipping item's data at LCN=2, LCN is now 1848
19:42:53           Skipping unmovable data at LCN=1848, LCN is now 1850
19:42:54           Skipping item's data at LCN=1850, LCN is now 28964
19:42:54           Yes, although there are some unmovable items between the LCN and the item.
19:42:54       Finished sorting by Name.
19:42:54     ZoneBegin is now 28964.
19:42:54     Updating list of unmovable files at: I:\Apps\MyDefrag\MyDefrag.dat
19:42:54     Loading file into memory: I:\Apps\MyDefrag\MyDefrag.dat
19:42:54       Finished updating list of unmovable items.
19:42:54     Finished FileActions.

edit: Aha! It's caused by SortByName(Ascending)... SortByName actually breaks up files over areas it says there's an unmovable file! So if an unmovable file is in the way, it will actually break up the file and put it there anyway. Aargh. I modified my script to use Defragment() and FastFill() instead of SortByName, and voila! All blue.

Strange, though... it is actually breaking it up over what appears to be freespace. Could that be caused by "hiding virtual clusters..." of the NTFS metadata?

Oh man, this is frustrating. Sometimes, when I run MyDefrag on a computer, it'll run and run and run, and for some reason it'll start crapping-out strings of yellow for no apparent reason! Files that were written by MyDefrag, with inexplicable spots of free space breaking the file into fragments - the bigger the file, the more fragments!

Have a look at this screenshot (attached).

Also included is my own homebrew mod of SlowOptimize (didn't create it for distribution, so the original comment's still there). It seems to be working, so I don't think it's the script, is it? It's intended to rewrite the entire drive and require a good amount of freespace. It's also intended to provide the exact defragmentation strategy I'd been desiring for very many years as I'd seen defragmenters blindly group totally unrelated files on the disk and do nothing for performance... hopefully this script, and strategy, will do what I'm thinking of!

Anyway, what's with those holes? Even with a standard SlowOptimize strategy, I've seen it crunch away on a computer and fragment it all to hell with freespace "holes"... that HDD had some bad sectors but _my_ laptop (the one I wrote this for) is totally OK...

I've always thought that language options are a very bad thing in a program - but hear me out. Language options are a very good thing to have, but they simply need not to be installed by default. Give the user one language choice in the installer, then later options via downloads. After all, who actually actively changes languages on a computer anyway? Today I want to read Dutch, today I want to read Spanish. I don't hear that from people They just take up space on my hard drive and sometimes I actually search and delete the extra language files that were installed when the only language I speak is English

On that note, I've got a bit of a... problem... with MyDefrag! It only speaks Dutch to me (and all this time I thought it was German)! I searched through this forum and stumbled on this topic, which sort of leads me to believe I may be able to switch English back on by removing the "language.MyD" file. But augh, what a pain, a program that is written entirely in English except when it's telling me what it's doing! Definitely on the tofix list, I take it

Other than that, god dang, MyDefrag is a _HUGE_ improvement over JKDefrag, which is already a huge improvement over other pieces of software. Still needs to be a bit more GUI-based in my opinion, but it's certainly getting there!

So I had an odd opportunity at school today, to try out JkDefrag for the first time. When I first tried it, it scared the hell out of me because it had no GUI controls and, from what I could see, no way to start it, stop it... and with that concern also came the concern of the data on a system that wasn't even mine! I damn near pissed myself. I hit Close immediately and it kept on spinning in the background. Augh! I googled on another computer (since the target system was running a tiny WinPE disc), and found this site, and that it was finishing up before it closed.

Okay, so it stopped, and I read a little more about JKDefrag. Neat. It uses the same API that XP's defragger does... so it doesn't touch the data. This is good, I really didn't trust it further than I could throw it. But less so, did I trust the alternative defrag, DefragNT, which never even started properly. Facepalm.

Well, the drive was packed, and heavily fragmented (I'm at home now, didn't keep screenshots), had about 5gb free after clearing everything. It was a 40gb drive with several students' virtual machines (vmdk files) on it. Three of them were "flat" images which had a lot of dead space. I NTFS-compressed those and the shed about 90% of their size (one 4gb file shrank to 1.5mb, it was all dead space). Now the drive had about 25gb out of 40gb free.

I started JkDefrag on it. It crunched away for about an hour. It reached 100% on "Defragmenting", and kept on going for another 10 minutes or so. Nothing on screen was showing up white, though. CPU usage was pegged at 100% and it kept rattling off stuff about moving 2 clusters here or 4 clusters there... I gave up and stopped it. The drive map was still a scattered disaster of green and yellow.

I rebooted into a section of the WinPE disc (since the computer's OS is locked down and I can't start a defragger) that had Windows' native defragger working, and I ran a pass on that. Windows' defrag took about 10 minutes and it sorted out all but the 4 VMware images. The drive looked nicely organized and packed to the front of the drive, except those VMware images scattered on the drive in red (about 4,000 fragments each). I ran another Windows pass, it finished in about 1 minute. Still didn't fix those files. Another. It finished about as fast as I could click. Still didn't fix them.

Okay, so I booted back into the other PE installation again (since for some god-forsaken reason, the mouse wasn't detected in that second PE install with working Win defrag) and ran JKDefrag again. It... well... it did exactly what the title of this thread implies. It ran in circles and accomplished a whole lot of nothing! 100% CPU, moving tiny numbers of clusters as fast as the screen would update. It was like it was defragging parts of the compressed file that didn't even exist. I let it try that for another 20 or 30 minutes before I said, screw this...

I kinda wanted to just bring this to light, maybe a bug, maybe something that should be addressed... I dunno, but it's really kindova show stopper.