while developing in the web framework Django, having opened a lot of the project's files and running a development server, Windows forced me to restart due to Updates. So I closed everything and restarted. After the restart my whole project directory that I was working on before (including ~20 files and subdirectories) had suddenly disappeared.
I downloaded and installed Recuva, which finds the files saying they are not deleted and that the path is E:\?\mydirectories. This path is not a valid path on the file system on Windows 7.
Do you have any glue what could have happened? Especially where I can find my apparently not deleted files?
If you have found your files then stop reading this and recover them to a separate device (flash drive or similar) - Now.
Right. Is it the ? that worries you or the e: drive? I assume you have an e: drive and it's the loss of the path that's the problem. This occurs when the full path back from the file to the root can't be reconstructed as the record in the master file directory for one or more of the directories has been overwritten. You will have to recreate the path manually then copy back the recovered files.
Did you use the option to Scan for Non-Deleted Files?
I can't understand 'where I can find my apparently not deleted files?'. Have you or have you not found your files?
If you have found your files then stop reading this and recover them to a separate device (flash drive or similar) - Now.
Right. Is it the ? that worries you or the e: drive? I assume you have an e: drive and it's the loss of the path that's the problem. This occurs when the full path back from the file to the root can't be reconstructed as the record in the master file directory for one or more of the directories has been overwritten. You will have to recreate the path manually then copy back the recovered files.
Did you use the option to Scan for Non-Deleted Files?
I can't understand 'where I can find my apparently not deleted files?'. Have you or have you not found your files?
First of all: thanks for the quick answer!
The files I'm looking for are listed in Recuva as "not deleted" and with the path "E:/?/..". I recovered them and did another restart as prompted. During that restart Windows ran checkdisk, so it also must have realized that something is wrong with the file system. Afterwards the files were moved to a hidden system folder called E:\found.000\ and spread around subdirectories called dir0000.chk, dir0001.chk,.. and so on. They were recoverable from there as well.
Trying to get my project to run by recreating some auto-generated managing files (not all files reappeared), I saw that my database was also corrupted. I fixed that by resetting it.
All in all this can be considered fixed, though I still don't know what the cause of it was. Due to it just affecting my Django project I now think it's some wierd combination of running development server and forced rebooting because of updates. It seems to be not a minor issue when an interpreted language damages the file system. Would be interesting to figure it out.
edit: I used the option for non-deleted files and am wondering how a file can be "not deleted" and have a path with "?".
'I used the option for non-deleted files and am wondering how a file can be "not deleted" and have a path with "?".'
In a normal scan Recuva will read the master file table and extract all file records with the in-use flag set to '0' (i.e. deleted). If Scan for Non-Deleted Files is checked then Recuva will extract all file records whether the in-use flag is set to '1' or '0'.
Each file record in the MFT has a reference to the MFT record for its owning folder, which also has an in-use flag. If the MFT is corrupted, as it sounds as it is, then the folder could have the in-use flag set to '0', or the owning folder reference could be invalid, or the record sequence number is invalid, or no doubt several other factors can cause an invalid reference. The inability of locating the owning folder causes the ? to be shown.
I believe a chkdsk should fix this, but as it has never happened to me I can't verify that.
Okay, thanks for the explanation. Now I understand.
chkdsk worked in fact moving the files to the above mentioned hidden system folder called E:\found.000\, where I could copy them (they were 100% intact) from using the console.