Defraggler 1.18.185 writes into MFT space

Hello !

After upgrading to version 1.18.185 Defraggler writes into the area that is reserved for the MFT.

To verify that this behavior is new, I reinstalled version 1.17.172.

After that, Defraggler works as expected again, i.e. the reserved MFT space gets not overwritten any more.

Operating system: Windows XP, SP3

File system: NTFS

Besides that bug (is it any?), it's a cool tool !

Thanks.

Could that bug corrupt file-systems (on SSDs)? Any new infos from the developers?

Dia

Of course it's a bug. The MFT zone is not supposed to be filled with normal data files. BTW, it is easy to reproduce. I installed version 1.18 and it imediately started to fill my MFT zone (NTFS, 84% free).

File corruption should not occur. It does not damage the MFT, but the MFT will get fragmented pretty soon. Same on SSDs, why would it be different there?

Same on SSDs, why would it be different there?

Because (as far as I know) the concept of reserving an area of disk is inapplicable on SSDs due to the wear-levelling process, as is defragmentation. On SSDs wear-levelling inherently causes fragmentation, fragmentation is good for reads, and defragging is bad.

Ah, OK, I see. So defragmenting an SSD (with wear-levelling) makes no sense per definition.

Anyway, are there any official comments about that behaviour? I mean, was that intentional and what was the intention or is there gonna be a maintenance build soon? Right now you can't use Defraggler without messing up you MFT.

Er, guys???

Any thoughts about that?

Apparently, my Windows XP has now moved the MFT zone to a new location, where there was enough continuous free space. But the $MFT file is now in the middle of normal data and apart from the MFT zone. I can't imagine this is the way it should be.

Ah, OK, I see. So defragmenting an SSD (with wear-levelling) makes no sense per definition.

Just a note to add. SSD's do not have heads, they are truly near instant random access (similar to RAM or ROM) and so do not need defragging to get "physical" performance improvements. Writing to them uses "Life" so avoiding unnecessary writes is important - another reason not to defrag.

There is theoretically, depending upon the file system, reduced performance due to fragmentation - e.g. FAT or FAT32 but considerably less so if NTFS or one of the Linux EXT formats is used. However to save the tiny delay which would normally be << 1% (considerably less than) would require knowledge of the actual detailed internal design which varies from SSD to SSD model. That is assuming this wasn't already optimised within the SSD.

Hi folks,

I just tried out version 1.19 of Defraggler.

It immediately starts writing into the Master File Table area.

So the bug is still not fixed in this version.

I will continue using version 1.17, which is the last version that works correctly concerning the MFT.

Btw., does any of the developers actually read this forum? It would be nice to hear your opinion about this issue.

Ah, now I know what they meant with writing in MFT area. I thought it meant CHANGING the MFT, as in corrupting it. But Moving it was not edxpected. Indeed can I confirm that my MFT was moved from teh start of the disk to the somewhat mid of the disk, in between normal data.

Ah, now I know what they meant with writing in MFT area. I thought it meant CHANGING the MFT, as in corrupting it. But Moving it was not edxpected. Indeed can I confirm that my MFT was moved from teh start of the disk to the somewhat mid of the disk, in between normal data.

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).

I just tried out version 1.19 of Defraggler.

It immediately starts writing into the Master File Table area.

Btw., does any of the developers actually read this forum? It would be nice to hear your opinion about this issue.

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.

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.

My question is, was this a bug or feature?

Did they have a reason, say, speed it up or anything?

What gives?

My question is, was this a bug or feature?

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.

Hi Guys,

we will surely look into this, as this should not happen. Still it is absolutely safe to use 1.19.

Best regards

Romanoff

Hello Romanoff,

thanks for that reply.

It's good to know, that the developers are aware of this problem and someone takes care of it.

I really like the Defraggler (and also the CCleaner).

Thank you for offering these great applications for free.

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

Great work!!!

Just installed version 1.20.

As mike42 already noticed, the bug is gone now :).

Thanks a lot!

Just installed version 1.20.

As mike42 already noticed, the bug is gone now :).

Thanks a lot!

Too bad. I liked that "bug". I have posted about it on another thread.