Let's get straight to the point, long story short:

I opened my pc and a pop up asked if I wanted to delete directly a folder and all its files as it was too big for the trash. I clicked "No" but it went deleting anyways... so I stopped it.

I tried several File Recovering Softwares (EaseUS, Recuva, Puran, etc) and all of them recovered the files but when I open them the pc can't recognize their format (or won't open them anyways).

I've read a post about a software called File Scavanger, I'll now try this one too, however if you have any other softwares (even for non-beginners) please let me know! I need to recover many file types, but the most important one is: .veg (Vegas Pro File)

Thank you for all thesupport you'll be able to give me, if you need any further infos please just ask I'll be ready to answer!

NOTE: Also I've installed the first Software on the same disk of where the files were deleted, so basically very few files were slightly overwritten (but not all of my case) now I changed the Download folder's directory.

P.S. I'm using an ASUS pc running Windows 10.

  • 1
    The first rule of thumb for deleted file recovery is no never write to the affected logical drive until the files are recovered. But if the files are recovered and still unreadable, it's likely that it has been damaged beyond recovery, no matter what software you use. – Alejandro Sep 2 '18 at 15:56
  • 1
    @Alejandro and yet in those programs the quality of the files is set to "Excellent" and some others to "Good" and some to Unrecoverable – FET Sep 2 '18 at 16:01
  • This doesn't look promising. The file format does not appear to be open, or even documented, so repairing with a hex editor does not look promising. This reminds me of how I learned the importance of backups. – Mawg says reinstate Monica Sep 3 '18 at 10:51

Nowadays this is very often caused by TRIM.

TRIM is an ATA command which allows the OS to inform the drive about ranges of LBA sectors the drive can use as it pleases. This is useful for SSD drives as those have a constant need for erased pages to write data to. In practice the sector ranges are not immediately erased, however they may be removed from LBA space in a matter of seconds. If such sectors are read by the OS or a file recovery tool, the SSD simply returns sectors filled with zeros without even actually reading.

enter image description here

TRIM is supported by most modern operating systems and SSD drives. Also noteworthy are so called SMR drives, they also benefit and support the ATA TRIM command.

File system meta data associated with the file is not 'trimmed' which explains why file recovery and undelete tools may 'detect' such files. However if files are selected and saved, it's simply saving the zero filled sectors the SSD returns.

Easiest way to check for this issue is opening a few of the recovered files in for example HxD. If TRIM is the issue at play then files will largely contain zeros.

On TRIM and non TRIM drives it may simply be the clusters previously allocated to the deleted files are already overwritten.

This can happen on an SSD too, if new data is written to LBA addresses previously associated with the trimmed sectors, the SSD firmware simply assigns new 'blocks' to those LBA addresses.

Again HxD and some knowledge about the file type you're trying to recover can help determine what's going on: Suppose you're trying to recover a JPEG file but since it's deletion new data was saved. A trained eye, or, you simply by comparing a known good JPEG to the recovered file, can determine if recovered file actually contains JPEG like data.

  • I’m accepting this as the answer as you went in rich details on the subject. I almost forgot about this fact but I think I ended up not recovering those files and your answer explains why. Now doing daily backups, that sounds the best way around this :) – FET Apr 9 at 6:48

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.