9/6/2009 10:45:51 PM #

Hi Irakli,

In a nutshell, this is not an issue with Diskeeper. When moving a file (as it is also done with defrag), every action is "atomic" - either is happens exactly as requested (and passes fs consistency checks) or it never happened. This provides the 100% integrity that is a must for moving files - especially in the case of defrag.

That said, as part of that atomicity, the pointers to the file location(s) is singularly overwritten with the new location(s). Those pointers are located in the MFT record(s) for the file. MFT records are 1k, and typically contain all file attributes (such as locations), and potentially some of the data (which is why secure delete tools must also overwrite MFT records as the feature in Undelete does!). When you have many, many pointers, it can require additional records be created for those file attributes. BTW - NTFS compression creates many additional file attributes.

It is possible that an interupted movement from a defrag operation can leave a file in more pieces than it started (perhaps due to backing off for foreground operations), thereby creating more pointers, and potentially more MFT records. It really comes down to the algorithms employed.

Theoretically it is possible with Diskeeper, but given we operate under the pretext of InvisiTasking (no impact to the system), we have put great effort into our algorithms to ensure this does not occur.

Based on previous questions and the depth of this one, I can tell you are fairly well versed with file system internals and can recognize that algorithms are a major distinguishing characteristic from one product to the next, so I left out some background info. For anyone else reading this I recommend the book "Windows Internals" published by Microsoft Press - it's now in its fifth edition.

PS: I removed the weblink, but I did read it.

michael