Jump to content
CCleaner Community Forums

Fractalogic

Experienced Members
  • Content Count

    22
  • Joined

  • Last visited

Community Reputation

0 Neutral

About Fractalogic

  • Rank
    Member
  1. Sorry! It appears that Recuva is unable to scan BitLocker encrypted drives: http://forum.piriform.com/index.php?showtopic=45792 I hope you had a backup of your files!
  2. Hi! I recently ran a Recuva file scan on the Recycle bin, which made Recuva scan all my local drives. One of these was my USB flash drive which is BitLocker encrypted. However, I had that drive unlocked before the scan began. But still, Recuva encountered an error. Failed to scan the following drives: \\.\HarddiskVolume2: Unable to determine file system type It successfully scanned all the other drives, but none of the other drives were BitLocker encrypted. So! Is it true? Is Recuva unable to scan encrypted drives? Thanks!
  3. Ah! That's interesting. It shows the address for some files, but not for others. Here is a PNG file info: Size: 167 KB (171 372) State: Not deleted Creation time: 2015-04-03 19:06 Last modification time: 2015-04-03 19:06 Last access time: 2015-04-30 21:09 Comment: No overwritten clusters detected. 42 cluster(s) allocated at offset 76944 Here is some JPG file info: Size: 544 bytes (544) State: Not deleted Creation time: 2015-07-16 11:58 Last modification time: 2015-07-16 11:58 Last access time: 2015-07-16 11:58 Comment: No overwritten clusters detected. Why is that? Why does it tell the
  4. Hi! I wonder... is it by any chance possible to figure out the offset address of the files that Recuva detects? I'm looking at a very important file in the list. Recuva reports the size as 405 KB and it has no overwritten clusters. But I have a reason to believe that this file is larger than that. It's not a huge file, but it is certainly larger than what Recuva is reporting. I would like to go ahead and use another program to pick up some more raw data at this location. The reason the size is reported incorrectly is probably because the file system entry for the file has been damaged.
  5. Wait... what? A 2 GB external drive from Western Digital? How old is that drive? What kind of interface is it using? What kind of computer is it attached to? Are you sure you didn't mean to say a USB drive? Those are external too you know, but then again... I don't think WD makes those. I didn't get that time reference... you lost what and when? You lost 15 temporary files at 3:30? Then what happened at 6:30? It's a good thing that you backed up then. But what you're saying is that you have made changes since your last backup that you would like to recover if possible? Are you kidd
  6. What is a fragment? Do you mean a cluster?
  7. A cluster is the same thing as allocation unit in Windows, right? If so, then this one is 32K. Is an "unrecoverable" file actually recoverable? If it is, then shouldn't the recovered cluster data be the data of the new file? And not the data of the overwritten file? I don't see how this "unrecoverable" JPG file can have been overwritten by another file, according to Recuva, an MP4 file. Because there were no new file write operations done after the JPG file was deleted. The suspected MP4 that supposedly overwrote the data clusters of the JPG file coexisted with the JPG file and was del
  8. Microsoft marketing campaign about the new Windows 10: "Your files are right where you left them." Yeah... right! Haha!
  9. I did some research after this incident. The "scanning and repairing" message actually means that Windows is running the CHKDSK utility program. The CHKDSK program is too primitive!... like many of the aging Windows components that keep appearing in every "new" version of Windows. This program can't handle encrypted data. In fact, it is often recommended that any FDE (full disk encrypted) disk be unlocked or decrypted before CHKDSK may be used on them, in order to avoid data loss. My disk was not encrypted, but this single file on it was in fact encrypted. As a result, it was the only one
  10. Yeah... all true! Indeed, I was going through a phase... now I'm just about done. Sorry about the bad language! Recuva actually managed to grab an old version of the file from the affected partition. It was not the most recent version, but it was better than what I had. I said I had an old copy, but I didn't manage to locate it. I must have misplaced it somewhere, or deleted it. Anyway! The file that Recuva dug up was good enough for me. I used that to build a fresh new file. Technically, I imported the recovered file into the new file. Then I added some new entries and made some edits as
  11. Hello! I'm looking at a microSD card here, and I can't help but wonder what the different file "states" as seen in Recuva actually mean. I have one JPG picture file that's "unrecoverable" and another that's "poor". But after I recover them both, the file that was supposedly "unrecoverable" is 100% OK from what I can tell by naked eye, while the file that was rated "poor" is missing the bottom half of the picture. What are the criteria for the various states to appear? Unrecoverable, Poor, Very poor, and Excellent? How can "unrecoverable" be better than "poor"? I would imagine that unre
  12. Thanks! I tried the KeePass repair method without any luck. How could it repair it? It's a 0 byte file. Is it beyond recovery then? I can't believe this piece of s*** for an operating system! I had Windows 8.1 installed on an SSD, system disk C, no partitioning except the RAW caching partition. I had the backup partition on a separate partition J, which is a mechanical HDD. Windows 10 should not have even touched my J drive. The reason it did the scan may have something to do with my previous Windows installations and my dual, triple, quad boot configurations with Windows 7, 8,
  13. Hi! I just realized that my KeePass database has been rendered useless by the Windows 10 upgrade process. I am still in shock! Toward the end of the upgrade process, Windows 10 did the m*****f****** disk scan and repair b******t and I remember seeing that it scanned my J: drive. This was my backup partition. I didn't realize until now when I tried to open my KeePass file that it has become corrupted. The file name itself is still there! But it's a 0 byte file! Is there any chance Recuva can recover a file whose file name is still intact but the data is missing? I mean, would Re
  14. I just accidently deleted a backup file. It's an Acronis True Image TIB file. Recuva 1.43.623 finds the file through the recovery wizard but it is unable to recover it. The "state" of the file is "unrecoverable". So the resulting file is 0 byte. The file was stored at H:\My backup and the name of the file was File_backup_2012-10-18.tib. Why does the recovery process fail? Is there no way to save it now? I have stopped using the H disk because I know it can affect my chances of recovering the file. I really need this file.
  15. Is there a good reason for this?... Perhaps it's because it would be contradictory to its mission, namely to keep the computer clean? That is not true my good man. I don't remember making any changes to the settings. I just had the latest version of CCleaner installed just to put this to the test. It defaults to having this option enabled. My memory serves me well. Check the screenshots for reference. I installed version 3.21.1767 but I previously had an earlier version, like version 3.0x something. It was not a much older version than the most current version. It could be th
×
×
  • Create New...