I'm pretty well aware that WAV (PCM) sucks for storing audio... but I'm not talking about my own computer here (I almost never am). This is someone else's computer, and someone else's data, used in some other program that reads/writes WAVs. So it's really not up to me...

LZ77? TTA? Huh? Just NTFS compression... unless of course there are different NTFS compression methods, in which case I'd be _very_ happy to know how to use them

Well... here's what it looks like after cloning from the 60gb drive to a new 160gb drive...



No more 2,000+-fragment files, but they're still all fragmented... I guess Ghost can't fix everything! Still leaves a job for MyDefrag, that's for sure

And the best part is? They're all NTFS compressed files (the program writes WAV files so the compression really helps). Much fun!

Or clone it to a new drive, like I said in OP

Just posting this for the lulz. If I wanted to defrag it, yeah, I'd move files off to another drive, defrag, then move the files back.

(edit: Also, yeah, not coming anywheres near that monthly script. My own script or nothing.  )

Here, after it finally finished analyzing (about 10 minutes later)

For lack of a "General" MyDefrag forum... I thought I should put this here. 

Really just a kick-back lulz thread to point out how bad things can get at the shop. The customer brought in this computer because they only had about 300mb of free space on their 60gb drive. It's all important data, recorded in real-time from a data capture device, so it's not temp or junk... they really are using their computer like this...!

We'll be cloning it to a new drive, which will defrag it in the process. MyDefrag would never be able to defrag a drive this bad without moving some of the data off first, and even then it's up for debate! (we need a :lol: emote)

edit: Hmm... one sec, I'm posting the image on imageshack, the attachment system here just dumps the whole full-res pic in middle of the post... oops

edit:

Maybe there is an easier solution to avoid shuffling, one that's already built into MyDefrag (and seems to be completely bug-free now): Add "DoNotVacate" to all of your gaps.
That way, if a file is in one of the desired gaps, it will stay there until it is moved by a zome command, which will really speed up things since MyDefrag doesn't have to push probably fragmented files from zone to zone while working on a disk.

It would be SOOOOOOOOOOOOOOOOO nice if it worked like that. No, because of the very linear way that MyDefrag thinks, you can't simply add DoNotVacate to a zone. If you do, apparently all the files "in the way" will simply be marked as processed (put in green) and it won't move them after that point. Really sloppy IMO, pretty much makes DoNotVacate entirely useless under all conditions (what if I wanted to move the next zone back to the beginning and then select those files?).

Large numbers of large files seem to be impacted just as severely...

http://www.youtube.com/watch?v=DCyE00Of4Lk

I caught that on tape today. I only later found that it's impossible to read the screen, but it was basically taking 10-15 seconds to move a 1.5mb MP3 file with no disk activity. The hard drive was packed with lots of large MP3 files, photos, and videos, but the drive was uniformly scattered. With the MoveToEndOfDisk being at the beginning of the script, it ended up just "filling-in" these files around the existing fragments/files. So there were a lot of tiny files in the way, as well as the files it had been moving.

Honestly, I'd prefer to see MoveToEndOfDisk take the size of the selected files (and not add the rest of the unselected files!), start a zone at the end of the drive minus the size of the files selected, and fill in from the top-down from there, as usual for a FastFill. The current method is pretty thorough as far as filling-in in order, but it's FAR too CPU-intensive and there are a lot of solutions to this...

It's a bug (or, more specifically, a not-well-considered design decision) that can be seen when moving many small files. It seems like MyDefrag examines the whole disk map - and attempts to move each file - to each and every available gap from the end of the disk upwards, and finally moves it only when it succeeds. So moving thousands of small files (a la Vista/7's DriverStore) gobbles CPU and gets very, very little actual data-moving done (hard drive light just flickers). I ran this on another 2GHz dual-core CPU - don't think the computers I use MyDefrag on aren't up to the simple task of moving files around!

I finally "worked around" the problem for the time being by just adding a boolean that excludes files smaller than 1mb. Then, it finally gets the moving done at a respectable speed, although still using a good amount of CPU for a relatively trivial task. I wrote about a potential fix in a topic in the Bugs forum regarding the issue, let's see how that goes.

Oof, can't believe I didn't have reply notification turned on. I really need to update this script for MyDefrag's even-newer grammar... I think I'll put up a new version once the CPU-bug in MoveToEndOfDisk is fixed...

Yeah, I've gotta say that's kinda a bum dismissal there, too. It does behave like a memory leak, in that restarting MyDefrag allows it to continue where it left off - sure, it re-analyzes everything and often starts "shuffling" files in FastFill zones, but it still picks up where it left off with significantly less memory usage.

I don't see why catching an out-of-memory condition and handling it by restarting is a bad option. Out of memory problems are few and far between on the many systems I work with, but MyDefrag's memory usage does get kinda high. It'd be nice to have MyDefrag handle it more gracefully...

I was going to suggest the same thing - I also experienced exactly the same behavior with 4.2.8. I'm quite glad to see there's a new MoveToEndOfDisk function, but this huge CPU-usage "bug" is a major tradeoff for a function that would otherwise speed up MyDefrag's operation

I think just "estimating" the next gap, based on the start point of the last placed file, minus the size of the file to be moved, without even asking for the diskmap, would massively speed up operation... if that area's not available than who cares anyway, right?

Hey. If it's been "discussed" that much on this board (rather, more like "requested and denied"), then isn't it obvious that people want it? I think a good number of sore points people have with MyDefrag are involving the installer - the installer being the first impression a program makes on someone. Why give a needlessly bad first impression when it's so easy to fix the problem people are complaining about?

IMO the version number (as well as the company name) should never be part of the program's directory. Even if the developer has a fundamentally different view of the way things "should be", the fact remains that the norm is NOT to put unnecessary info in the program's folder name. And in the case of MyDefrag there's really no reason to have two versions installed at once. The scripts get updated with a new install, and if someone (such as myself) writes their own scripts, having them broken with the new version only means they need to be updated with the new grammar. There's really no reason to have two versions along side each other. I wish it were as easy to update MyDefrag as simply installing a new version. Actually, I wish it were as easy as just extracting a ZIP to the MyDefrag share on the server, but that may need to wait til the next version

I just saw the new MoveToEndOfDisk fileaction in 4.2.8... THANKS! That should allow me to move Spacehogs out of the way in the first action, so it doesn't keep tripping over them zone after zone after zone (move above zone 1... move out of gap... move above zone 2... move out of gap... move out of zone 3....etc.....place in zone 7). IMO that'll dramatically improve MyDefrag performance.

It's better, if the actual placement can't be predicted (scan all zones first then assign each file to a "zone" and vacate them near their final area), then moving then once to the end then once to the final zone is better than moving over and over and over. And since MyDefrag scans the diskmap for each file move, the less number of total file-move operations it needs to do, the better. I think it's all around a great idea and I'm very much looking forward to implementing it later today!

That's what I thought at first as well. But then I thought about how MyDefrag locates a gap to move a file into, vacates a gap, etc., and realized how big a task it would be to make these things "virtualized". The graphical display is just a display of what it's thinking on the inside... perhaps it would be able to use the disk map and known file layout to test a "perfect conditions" scenario, but that would still take a lot of work to virtualize the "information gathering" parts of moving a file (such as "is this spot available?"). But maybe Jeroen could confirm/deny that