mike42

I wonder if anyone knows, what new features the Version 2 will bring? Mike

Yes, unfortunately it is. But I think I saw it only after defragging a single file. But I'm not absolutely sure about a complete run.

I can confirm this. Defraggler DOES defrag the $MFT.

You have to understand that Piriform software comes free of charge and the guys have to get money from somewhere. BWT, if you go to the builds-page (somewhere in the download section) there is a so-called 'slim' installer that does not include the toolbar. And I also can't reproduce the display bug on a Win XP SP3 machine.

As of version 1.20 the bug is resolved. Defraggler leaves the MFT zone alone now as it should be. Great work!!!

It never did. Apparently your pagefile never was fragmented so far, so you didn't notice. Personally, I always set the pagefile to a fixed size right after windows install. Then it can't get fragmented in the first place. That has been promised for years. Don't wait for it. For a one-time operation you might use 'pagedefrag'.

Don't mix things up here. The problem with the MFT is that Defraggler writes into the MFT reserved zone, hence causing fragmentation of the $MFT file in the future. However, it does NOT screw up the MFT, meaning it does NOT currupt it.

I wouldn't exactly call this a bug. Maybe it is just some unlucky wording. I understand the checkbox in the installer as "Do you want to check for updates during install?". Maybe that has nothing to do with the settings in the program. But you definitively don't have to put the settings in an ini. You can disable updates in the settings and still keep them in the registry. I never put them into an ini and disabling updates works for me.

No, it is not. That thread was about the map AFTER defragmentation not showing correct color (fragmentation status) of individual squares and content (how many / which files). I don't think so. Especially when dealing with very large files, where each takes several minutes to be moved I'd like to know what's going on.

When defragging, the colored drive map should display where Defraggler currently reads (yellow) and where it writes (green). When it is working on small files this works OK. But when there are a bunch of large files (CD images, huge video files, ...) the green and yellow blocks often don't change for minutes, even if meanwhile a different file is shown in the status. In this case, only pressing Pause (and then Resume) updates the drive map. AFAIK this is new since v1.19.

As I said, the OS would never write user files into that zone, unless the regular free space is used up. If Defraggler forces user files into the MFT zone, the OS will automatically relocate the MFT zone and thus start a new $MFT fragment, which cannot be the intention of a defragmenting software. So I think it is a bug. But that is exactly, what I would like to see explained by a developer.

Honestly, I'm a bit unsatisfied with this situation too. I often miss reaction here by the devs. I always try to be constructive in this forum and I really hate to complain since the devs are certainly busy and Defraggler is free and everything. But what is the use of a bug forum if the devs don't react on certain issues. How can there be a new release still containing a (quite obvious, at least to me) bug. Especially if this bug was entirely new in the previous version. Please don't get me wrong, after all we (the users) are trying to help to improve the software.

Just to clear things up: The $MFT file ist THE actual master file table. The "MFT area" or "zone" or "reserved space" or whatever you may call it (the stuff colored in purple by default) is an (unneccessarily huge) space, 12.5% of the disc by default, reserved by the operating system directly behind the $MFT file. This is to enable the $MFT file to grow without getting fragmented. The operating system never writes data into that zone except MFT entries, for which it is intended. Since v1.18, as soon as the disc is filled up to the MFT zone during defragmenting, Defraggler happily continues to write user data files sequentially right into that MFT zone, ie. right behind the current end of the $MFT file. Upon the next system reboot (or remounting in case of a removable drive) the operating system will assign a new MFT zone in a different area of the disc and continue the $MFT file in that new place. That means of course, that your $MFT file has two fragments now. Concerning this issue, I never saw any corruption (changing the logical content) of $MFT. But I had the feeling once, that Defraggler was defragmenting my $MFT (changing the physical position on disc). However, Defraggler cannot influence the position of the MFT zone directly (only by illegally writing user data into it).

+1 All those $-files and I think the hibernate file too.

I saw this too. The color map does not match to what I get when hovering the mouse over the squares.