0 byte files (as hard links) in “Extra found files”

A forum on data recovery using the professional data recovery software R-STUDIO.
abolibibelot
Posts: 30
Joined: Sun Jan 31, 2016 5:45 pm
Location: France

0 byte files (as hard links) in “Extra found files”

Post by abolibibelot » Tue Jun 02, 2020 6:35 pm

I made a recovery of a Windows 7 system partition on a 500GB HDD using R-Studio, and to my surprise, it identified a bunch of empty files, i.e. files with a “0 byte” size, inside “JPEG Digital Camera” (9 out of 8538) and “Text Document” (8 out of 229971). Those files are hard links of files identified through the analysis of the filesystem, under “Root”, but if they are present in those “EFF” sub-directories it means that they were also identified by their file signature matching those particular file types, which of course is not possible for files with a size of 0 byte. I thought that it could mean that the filesystem was somehow corrupted between the moment I made the scan and the moment I made the extraction (Windows crashed in between, I used the saved scan information later on to proceed with the extraction) ; to verify this, I re-made the scan from scratch -- and the result is the same, there are still “0 byte” files appearing in R-Studio's explorer in “JPEG Digital Camera” and “Text Document”, same number and same names. Those files seem to be all hard links to files in “Root\Users\[username]\AppData\Local\Temp”. There are many other “0 byte” files in “Temp” which do not appear as hard links in “Extra found files”. How can this be explained ?

Another issue with Extra found files :
That 500GB HDD contains three partitions, a 14.65GB “Recovery” partition, a 116.44GB “System” partition, and a 334.67GB “DATA” partition, but in R-Studio's file explorer, for each identified partition, the “Extra found files” virtual directory contains files which are actually located on the physical space corresponding to other partitions. For instance, there are large video files from “DATA” which appear in “Extra found files” on the tab corresponding to the “System” partition, without being linked to the corresponding files identified through the analysis of the filesystem. The same large video files appear in “Extra found files” on the tab corresponding to the “DATA” partition, and there they appear as hard links, with the names and timestamps of their counterparts in “Root”. So if I want to do a thorough extraction of the whole drive's contents, since there's no easy means of selecting only the files in “Extra found files” which are located within the physical boundaries of the currently examined partition, the only solution is to extract everything, which generates a lot of duplicates, and then use a duplicate remover to painstakingly sort out that mess. So there should be either one single “Extra found files” virtual directory for all partitions, or an option to limit the displayed “Extra found files” for each partition to the files actually physically present within the boundaries of that partition, excluding files physically belonging to other partitions. (I hope that this is clear enough.)

Yet another issue / suggestion :
There should be a clear distinction between the “Extra found folders” (orphaned folders identified through the analysis of the filesystem) and the actual “Extra found files” (identified by means of file signature search). Sometimes there are a gazillion of orphaned deleted folders overcrowding the “Extra found files” virtual directory, with names like “$$$Folder215405354”, and generally those folders contain nothing interesting, as the files they used to contain have generally been overwritten. While files in “Extra found files” are almost always valid files (unless they are false positives, or truncated in a way that makes them unreadable).

abolibibelot
Posts: 30
Joined: Sun Jan 31, 2016 5:45 pm
Location: France

Re: 0 byte files (as hard links) in “Extra found files”

Post by abolibibelot » Fri Jun 05, 2020 5:13 pm

As a follow-up to what I wrote about the redundancy of “Extra found files”, it should be noted that on this 465.76GB HDD, the identified “partition size” for each partition appears (under “Properties”) to be the total of the sizes of that partition + the ones that come after, which may partly explain the observed behaviour.

Code: Select all

[Device View]
Label : RECOVERY
FS : FAT32
Start : 1 MB
Size : 14.66 GB
[Properties]
Name : Recognized12
Size : 465.76 GB (976771120 Sectors)
Partition Offset : 1 MB (2048 Sectors)
Partition Size : 465.76 GB (976771120 Sectors) => wrong
Recognized FS
Estimated Size : 14.66 GB (30744202 Sectors) => right

[Device View]
Label : Système
FS : NTFS
Start : 14.65 GB
Size : 116.44 GB
[Properties]
Name : Recognized6
Size : 451.12 GB (946056888 Sectors)
Partition Offset : 14.65 GB (30716280 Sectors)
Partition Size : 451.12 GB (946056888 Sectors) => wrong
Recognized FS
Estimated Size : 116.44 GB (244187999 Sectors) => right

[Device View]
Label : DATA
FS : NTFS
Start : 131.08 GB
Size : 334.67 GB
[Properties]
Name : Recognized7
Size : 334.68 GB (701868825 Sectors)
Partition Offset : 131.08 GB (274904343 Sectors)
Partition Size : 334.68 GB (701868825 Sectors) => almost right
Recognized FS
Estimated Size : 334.67 GB (701863721 Sectors) => right

It would seem like files actually located on “DATA” appear on “Système”, with an offset added to the value of the first sector corresponding to the difference between the partition offset for “DATA” and the partition offset for “Système”, but not the other way around, as it would result in negative values. For instance, there is a “0537921.avi” (size = 1466025984 bytes) present in both tabs, its first sector is displayed as 242854992 in the “DATA” tab, and as 487043055 in the “Système” tab. And 242854992 - 30716280 + 274904343 = 487043055.

After extracting everything from both the “Système” and “DATA” partitions, and after I had already deleted a lot of duplicates between the “Extra found files” folder from “Système” and the “Data” folder, I ran a scan with DoubleKiller between the two “Extra found files” folders (the one from “Système” and the one from “DATA”), set to detect files with the same size, same CRC32 and same name, and it found a whopping 165253 duplicates for a total of 20.3GB (the exported list of duplicates is a 35MB text file).

Post Reply