Quote:
I used "GetDataBack" and it found the file name but 0 Bytes of file size.
Quote:
Your only hope is if the master file alocation table is still intact and does still have the entries for your deleted file, and i believe that at this point it doesn't so it's game over....
I read that when files larger than 4GB get deleted, the complete cluster chain can no longer be retrieved, since it's too large to fit in a single MFT record. See this post (and thread) for more details :
viewtopic.php?p=256553#p256553Quote:
https://forum.piriform.com/topic/36987- ... ecover-it/Quote:
If it's more than 4 gb (or was, and I guess an image file could well be) then Windows erases the file cluster adresses on deletion. The data is still on disk but the entry in the MFT no longer points to it.
Quote:
I think that Recuva has, in the last release or two, changed the way large files are reported. Previously, deleted files over 4 gb in size would be reported as zero bytes, and unrecoverable. Now it appears that the file size is reported, but with the comment that 'File's data could not be found on the disk.' Although NTFS zaps both the file size and the cluster run info in the $Data attribute in the MFT record, the original file size is still available in the $File_Name attribute (although not necessarily accurate). Perhaps this is where Recuva finds the info. If the file is under 4gb but in many extents then it may have forced the $Data attribute to become non-resident, i.e. to be held in a second MFT record for the file. In this case NTFS will, on deletion, zap the cluster run info in the MFT extension record, so the file is unrecoverable. It appears that Recuva also reports these files as 'File's data could not be found on the disk.'
https://forum.piriform.com/topic/38062- ... -and-more/Quote:
I have found, from experiment and from comments elsewhere, that NTFS manages deletion of files larger than 4GB differently from those smaller than 4GB. In the smaller files the entry in the MFT is (relatively) simply flagged as deleted, and the dataruns – the fields that hold the address and number of clusters for each extent – are untouched. This is how Recuva can find and recover the file data. In files larger than 4GB the dataruns are overwritten by NTFS. Although the file size is still available, the addresses of the data are not, and Recuva will show the Data not Found on Disk message. In this case no recovery programme can recover data from information in the MFT.
This also happens in smaller files which are in many extents. If the list of extents is too long to fit into a single MFT record it is placed in a MFT extension record. These too are erased on file deletion, leaving the file data unrecoverable.
Quote:
You might want to try R-Studio, UFS explorer, DMDE, etc ...
And you might want to create an image of the drive (or the partition where the file is/was at least) to avoid the possibility of messing with it inadvertently while trying a bunch of different methods.
R-Studio, and even Recuva possibly (with the “Deep search” option activated), could locate the file by its header, which is called “raw file carving”. Then if you're lucky and one of these softwares does find a 10GB RAR file (it won't have its original name, expect something like “000035.rar” in R-Studio or “[000035].rar in Recuva) and it's not fragmented, you should be able to extract it in one piece right away and the password should work.
Photorec (companion program of TestDisk) is specifically designed for raw file carving ; although you can uncheck all file types except RAR (otherwise it will extract a gazillion of files of various types, everything that matches a common file pattern), it's less convenient than the other two as it will extract all RAR files it finds, but if the file you want is fragmented it will attempt to connect fragments – it
may work in a simple case, for instance if there are two fragments separated by one other file, it's worth trying but I have yet to see it actually recover one fragmented file.
Failing that, maybe analysing the whole MFT could allow someone with knowledge and patience to find the required data to piece together the complete file...
Quote:
But doesn't the blocks of file stored on the drive have headers info about the next block? something like "Linked Lists"?
I suppose there must be some headers and also the header is not encrypted. Correct me if I'm wrong
If I'm not mistaken, that's not file headers you're describing but MFT records (on a NTFS partition, which is probably what you have if you tried using GetDataBack). And as far as I know, no, there are no such things as header informations regarding the location of the next blocks within the files themselves, at least not for RAR archives, the cluster allocation information is all in the MFT.