Lite

The goal was a bug report. And naturally, this can add problems, since with a complete restoration it is said that it was not completely restored. Thus, the recovered will still have to be checked, and these are unnecessary operations. If you can’t fix it now, then at least take note. Perhaps someday we will realize what could be the reason and this will be fixed in future versions. There is clearly some kind of error in the algorithms. In general, this is all very strange. Thank you.

There is nothing different, except that it is significantly larger than the others (856 GB). Regular NTFS partition. The rest, no matter what they are (NTFS, ExFAT), behave normally. The check was aimed at showing that the data is being restored and the status with a message about partial recovery is a fiction. And also to confirm that this always happens to this partition, regardless of how much time has passed since the files were deleted. Even if they are deleted a second before restoration, they will definitely be yellow and have an uncertain status with partial recovery message. Some kind of mysticism.

I clearly wrote that the recovery is complete. I did an exact bitwise comparison. If this makes it clearer, then the checksum is completely the same. If you still don’t understand, I deleted these files specifically for verification. I have the originals. The recovered files are completely identical. Thus, this is only an incorrect program report. Something prevents the program from understanding the state and correctly interpreting the recovery percentage.

Fine. Now I see what's really going on. This behavior occurs only on one partition; on other disks and partitions the color indication is normal. The whole thing is in an unknown state. The files were restored correctly and completely (made a bitwise comparison). But for some reason it says that it has been partially restored. What could be the reason for all of that?

No. Even when integrity is excellent the mark is yellow. Or when it’s really bad and should be red, it’s also yellow. I said that in version 1.53.2083 everything works as it should.

Hi. Recuva 1.53.2096. The color indicators do not work - they are always yellow. The latest version they worked in is 1.53.2083.

The program is able to define timings. Whether is possible to make that the program gave the information what registers of detected chipset are responsible for timings and other detected memory features (Refresh Period, Memory Interleave) and show known values and descriptions of bits of these registers? With this information the advanced users can finetune a memory subsystem. Thank you.

I don't say that this shell extension don't work. I just say that this is possible. About REG. This is your original REG file, but with added strings. Where is "<--- Incorrect!", that is original string. Where is "<--- Correct!", that is modified by me string. By the way, I use shell extension already for a long time, have made it myself (place Defraggler to another place ) and at here did not look at all. As you can see I only recently here were registered. Passing by has decided to look. I simply wished to give advice, that's all. You can delete a topic. Anyway thanks. As my first topic has remained without the answer. Heh) P.S. Why Defraggler don't have this option built-in?

The path in quotes - a rule of a good tone. If the path contain spaces, then the command line without this quotes can be interpret incorrectly. Do you guarantee that your case always will work normally? Bright example - Opera 9.63. Developers have forgotten to put inverted commas in transfer of a command line. Try to use oGet on Opera 9.63 and you will see this: In this case (Defraggler) all work fine, but... I thought it it is known to everyone who is not only the user. If don't trust me, then look at registry entries from known software products like: Adobe Reader 9, Foobar2000, Foxit Reader, Nero, WinDJView, WinImage, Wordpad))), Daemon Tools, Media Player Classic, Photoshop, and so on. Well... I have warned you.

To Andavari Please Repair this!!!

Yeah. I almost forgot about this. Option like "Ultrafaast Defrag" or "Ultra DefragglinG", when files temporarly placed fully in physical memory on something like "Invisible RAM Disk", instead of shuffling them on HDD. This would be a great speedup and also reduces necessary free space at which defragmentation is possible. But this meens that you should have UPS (Uninterruptible Power Supply) for safety. If you mean this, then I join to request.

When do defrag of file on "Highlighted" tab, then "Highlighted" tab is closing and selected file is showed on "File List" tab. The Picture representation of "Interactive Drive Map" and "File List" tab is updated, but text representation of "Interactive Drive Map" that is "Highlighted tab" is still remains OLD. Please make the defraggler to not close the "Highlighted" tab when defrag from this tab. "Interactive Drive Map" is not fully interactive. When chosing a file on "Highlighted" tab, it not shows this file and all it's frangments on Drive Map.