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