Did you try R-Studio ? (Make sure you check the .vhdx file type in “Known File Types” options before you scan.)
You could manually scan the whole image (using WinHex or similar) with a constant and specific enough fragment from the .vhdx header, but if the lost file was fragmented it will be “virtually” impossible to recover it in its entirety – and it's unlikely for a 288GB file
not to be fragmented, especially if it's a type of file that grows and shrinks while being used (I don't know if it's the case with these).
What's surprising here is that Recuva does give you a size, which is apparently correct (you'd have mentioned it otherwise, wouldn't you ?), but still doesn't let you extract the data, I haven't seen that yet.
But I just made a test with a recent version (1.53.1087), on a 100GB partition of my SSD : indeed I get the same result for some (large) files (MP4 video files downloaded on that partition which were transfered and deleted weeks ago), either in quick scan mode or in deep scan mode : the names, sizes and timestamps are all valid, but I get the same « File's data could not be found on the disk » comment ; and there's no header whatsoever.
I don't know what it means. Normally, when MFT records are found by a data recovery software, even if the former data has been overwritten it's still possible to extract the corresponding clusters, although the resulting file will be garbage (either unreadable or readable but with a different content). And normally, with Recuva, if the file's actual data appears to have been overwritten, there's a comment saying that « This file is overwritten with "X:\Path_of_the_file\Name_of_the_file.ext" ».
I then scanned the same partition with R-Studio : surprisingly, it doesn't even display the names of those files which Recuva deems unrecoverable (I even tried the “Find/Mark” function to verify if they could be somewhere else in an “extra found folder”, to no avail).
Does anyone have a clue ? How could the free Recuva get at least those names and attributes, when the heavy-duty R-Studio couldn't find any remnant at all ?
{The following method won't work, I let it as part of the thought process, it may contain hints to a possible working solution...}
You could run nfi.exe on the whole image :
- Code:
nfi X: >Y:\Drive_X_nfi.txt
then open the report and search for the name of the file you're looking for, which might be in several places – but apparently in the MFT, and in nfi's report, a large file can be refered to either by its regular name, or by its short 8+3 name, I'm not sure how it works exactly.
Then, if no recovery software can detect the file, but if you're still lucky enough that all its fragments are intact, and if you manage to get a complete list of the clusters it formerly occupied, you may be able to use the painstaking method I detailed
here. That's a long shot !
=> I made the test : extracted the whole nfi report for the 100GB partition, opened it, searched for the names of several of the files which « could not be found », there's no trace of them... so you can probably forget about nfi, which only reports information about files
currently allocated, and the aforementioned “rebuild” method – unless you have somehow saved any file which could contain the clusters location information
before the deletion ! (In my case I had saved several reports because I knew those files had bad sectors. And I shouldn't have needed that tricky method if I had made sure that the whole MFT was extracted before attempting to recover those files.)
But there must be
something left in the MFT, if Recuva gets the names and attributes...
I then scanned the MFT with WinHex for a part of the name of one of those files (in Unicode) : the name does appear, the timestamps appear, but I can't find the cluster location data (it must be coded somehow).
I then scanned the whole partition : it also appears in the $Logfile, and also in (what used to be) the parent folder. Nowhere else (and nothing is found if searching in ASCII).
I don't have a deep enough knowledge of the MFT / NTFS structure to analyze this further.
Oh, by the way : if this was stored on a SSD, with the Trim command enabled as it should be, you're almost certainly SOL, sorry...
