Eld0r

Si So I think the reason is the wrong destination cluster. when you read attributes of the same compressed file and get for size 4GiB and for file size on disk 1GiB. And move it to end of drive for size - its only possible with a 3GiB gap after it. So calculation for destination cluster should be G := GetTheLastBigEnouthGap (for size on disk) And then use the IndexOfLastCluster (of G) minus the AnmountOfClusters (for size on disk) So you get the correct Position for the C := FirstClusterOfCompressedFile. I would bet, if you told the API to move the file to this Cluster C, then there is no gap after moved compressed files any more. Of course any calculation should use size on disk, because this shows the true physical size wich is important for defragmentation.

Seem like it's the general handling of compressed files. If possible please try to use always the property 'size on disk' instead of just 'size' for files & directories. Or is it the standard defragmentation API from Microsoft? Actually it should able to handle this decades old feature of NTFS. Would be nice to store the files without gaps at the end of disk.

First of all: when you say it stops do you mean it finishes defrag with remaining fragments? Or do you mean defraggler crashes? There are sometimes files, that can't be defragged (e.g. locked in use by programs). But my Defraggler never stopped leaving more fragments than before. So I would recommend you to check your hard drive. Defraggler may stop because of read/write errors. At first please check your hardware: - HDDs should be firmly mounted - cables not kinked and all contacts clean - Do everything to minimize vibrations If you checked the above, you can try the SATA SSC (Spread Spectrum Clocking) jumper setting. - This can reduce electromagnetic intefferences - Check the data sheet of your harddrive for SSC (Examples) And of course check your partition with chkdsk or any other program - E.g. Windows partition C: cmd > chkdsk C: /f /r I recommend to get a replacement hard drive. A failure in the near future (weeks or years) is likely. It can take longer if the errors do not increase after the above mentioned measures. For everyone: Everytime have a backup of your important data. (@mta: Just read your signature - so true ) Evaluation In the 424 days of your Spin-Up time (9) you collect interessting statistics: You got a few Reallocated Sectors (5). This value is a main indicator for failures in the next months. Of course Reallocation Events (196) increase too. All of my HDDs are at or around 0 (Spin-Up times over 300 and 400 days) Your G-sense Error Rate (191) is very high. You really should avoid these! This may lead to your high power-off or emergency retracts (192). Of course Load Cycle Count (193) increase too. My more stationary laptop count <3200 G-sense Errors (335 online days) Your Load Cycle Count is high but still okay (most HDDs are designed for >200k). Bad luck, if you lost in HDD roulett and got sensitive one. The vibrations may also cause the SATA Downshift Errors / Runtime Bad Blocks (183) (description depends on your hard drive manufacturer) Bad cables/contact or electromagnetic inteferences can cause these errors. See S.M.A.R.T. - Wikipedia from 2017-03-19 05:40 for table with descriptions (I checked this table, with trusted sources in my language)

I saw the green highlight for writing a file is much bigger, than the yellow for reading. For normal defrags I would think of sth. like a view bug. Of course the space behind the file is free, so a normal defrag to the lower sectors create no gaps. But I got gaps of 3GiB free space between the moved files and the actual End of Drive. I only noticed, because I got big and effectice compressed backups files. So this 4GiB files are compressed to 1GiB with NTFS. Defraggler highlight the correct sectors in overview. I marked the files and told Defraggler to move them to End of Drive. Conclution: Defraggler checks the space for a uncompressed file and aligns the compressed file like it is not. And this repeats for all compressed files. The gaps can -of courcse- only be filled with files <3GiB. When they are smaller and also compressed there is a gap again (behind and also before them). And so on... Hope you can fix the calculation/moving of compressed NTFS files so Move to End of Drive works again. I volunteer to become a beta tester. regards Eld0r

Hello, the specific core information shows the core clock at the time analyzing the Cores. A update timer - the same timer (?) - like the one from the multiplier would be really nice. Cause the multiplier get permanent updates, but not the core clock... This is what Speccy shows me (german): CPU Intel Core i7 2620M (...) Bus Takt 99.8 MHz Kern Frequenz 2700 MHz Bus Frequenz 100 MHz (...) Kern 0 Kern Takt 2693.7 MHz Multiplikator x 8.0 Bus Takt 99.8 MHz (...) Kern 1 Kern Takt 3192.6 MHz Multiplikator x 16.0 Bus Takt 99.8 MHz (...) - right actual multiplier of x8.0 / x16 (idle / some background tasks) - wrong "actual" (?) core frequency of 2693.7 / 3192.6 MHz (max: x27 / +Turbo: x32) actual frequency would be nice. Thanks, Till