Just a note - I don't expect to recover any files. This is more of a 'how do I deal with this not-so-recovered file and also you might want to take note of this sillyness' question. I'll probably end up deleting it.
A stealth windows update update taught me to leave automatic installation off, as it installed a shiny new amd sata driver and rendered the os inoperable (bsod on startup), and system restore errors with "Generic error" on restore (Even though there were many perfectly valid and intact restore points, even one right before the drivers were installed. Having limited access to disk space, I made a new partition on empty space, installed a fresh copy, packaged the old partition's contents with diskwizard. Deleted the files besides the tib file, tried to use gparted to shrink the partition and resize/move my windows partition. Worked fine except apparently the "Actual size" of the tib was far greater than anything reported, so I ended up clipping the last two gigabytes of the actual size off. My blunder. ChkDsk /f rendered the partition it was on mostly empty (as it should with junk data).
I looked up file recovery methods (not knowing that a file of its size, ~ 122GB actual, (though it only reported 117GB, was probably unrecoverable anyways due to how ntfs works.), Found recuva. Used it and a number of other recovery methods, and recuva was the only one that was able to find a $BadClus file of about the right size on the empty partition. I initiated the recovery to another partition, and it followed through and reported success.
Now here's where my problem starts. The file it wrote is 0 bytes, which apparently is expected behavior, but the space was *still* taken up.
Using windirstat and showing unkown files, there's a big unknown blob of about 120GB used on my hard drive.
I've tried running chkdsk /f, as well as /r, on this partition. Multiple times. As well as taking a look at it with other OS like ubuntu.
Is there a way I can recover this file?
If not, I might be able to delete it.
I was running space sniffer with Alternate Data Streams on and the $BadClus file actually shows up as the unknown blob and some limited data can be gleened but not much else. Seems that the 'unknown blob' moves with the reportedly 0 byte $BadClus file (If I move it to the recycle bin and then restart the os), so I blame NTFS for this.
The file is otherwise unmovable and seagate diskwizard doesn't want anything to do with it.