| Author | Message | ||
     Jeroen Balduyck Username: jeroen1000 Registered: N/A |
Hi guys, First time poster long time lurker  . I'm at the end of my beef here. Please bear with me. I'm looking whether Winhex can provide a cure for this issue. - An orphaned or lost file does not have an MFT entry, yes? - A free space wipe shouldn't delete an orphan because it technically is not free space, correct? - The only way to identify the orphane file type is by using a signature, correct? Now comes the important one: The only way to find these orphans is to scan every single cluster of the drive and check whether it is empty or not. If it is NOT empty AND there is no MFT entry, the file is indeed an orphan. How can I get rid of these orphans? | ||
| Alfons Kramer Username: admin3 Registered: 4-2004 |
There are several situations imaginable where such 'orphaned' files can occur. In either case it is considered an file system inconsistency. The classical way to deal with such inconsistencies is by running a file system check. After such an check files will either have an normal existence or they'll be in the free space. WinHex will classify such orphaned objects as 'idle space' (not to be confused with free space). Idle space gets usually identified during running "Particularly thorough file system data structure search" from "Refine volume snapshot". Idle space is neither allocated nor free - something in between. | ||
| Jeroen Balduyck Username: jeroen1000 Registered: N/A |
A chkdsk does not seem to fix this issue. I thought Windows put these files in a 'LOST+FOUND' folder? This "Particularly thorough file system data structure search" probably scans every cluster of the drive? | ||
| Jeroen Balduyck Username: jeroen1000 Registered: N/A |
I'm running checkdisk with the /r parameter now. Perhaps this will get rid of the lost files then. | ||
| Alfons Kramer Username: admin3 Registered: 4-2004 |
'LOST+FOUND' is a UNIX thing. "Particularly thorough file system data structure search" indeed does scan every cluster. The /R parameter is required. Addition: Orphaned files can also be found with WinHex in the folder 'Path unknown'. | ||
| Jeroen Balduyck Username: jeroen1000 Registered: N/A |
How can Winhex find reference to them without a thorough disk check? I did have such a folder though. GetDataBack also presented me with that folder but also found additional lost files. That folder (the one Winhex presented) was gone after I initialized the MFT records or cleaned the slack. Don't know which one of the two did the trick. I've got this funny feeling checkdisk /R hasn't done a single thing as it reported 'no errors found' or something in the likes. | ||
| Alfons Kramer Username: admin3 Registered: 4-2004 |
Things are more complex with WinHex, because it finds deleted files too. Sometimes previously existing files cannot be associated with a toplevel folder. More complexity gets introduced when GetDataBack is installed. It archives older versions. If chkdsk.exe does report 'no errors' then there are no orphans from the file systems perspective. | ||
| Jeroen Balduyck Username: jeroen1000 Registered: N/A |
You are correct, after /R all are gone but one folder. I then did a thorough disk check with Winhex and examined the folder with 'path unknown' files. When I click on one of these files I can see they belong to a restore point residing in the System Volume Information folder. Perhaps checkdisk does not interfere with this system folder. I'm guessing that is why I can still find reference to them. Then we have a few files with a red cross over them as well. These files do not belong to a restore point. I checked and they are recoverable. Would you agree that when I use Winhex to erase free space, they should be gone? For the resident one's I will reinitialize the MFT as well. I have found this session most informative, thank you for this. | ||
| Alfons Kramer Username: admin3 Registered: 4-2004 |
Erasing the free space should do job. You can always use WinHex to check for success. |