Question HDD after chkdsk does not have all data accessible, and some stored in folder named "found.000" ?

[The Electro Machine]

[First - how it happened:]

On my Windows 10 Enterprise 20H2 x64 I have 2 archival HDDs with different letters assigned to them which I keep offline: 3.5" Western Digital Ultrastar DC HC550 18TB 7200 RPM 512 MB cache [0F38459] and its smaller counterpart DC HC550 16TB [0F38460]

I have been cleaning them thus connecting them back and forth as I never have both of them temporarily working at the same time. And then for a week I have been [most of the time when my machine was on] using freeware Disk Fresh on the 16TB one to read and re-write every bit, to avoid data fade / bit rot. I performed multiple resets of system during this process, never disconnecting 16TB and / or connecting 18TB. And after it was finished I defragmented it using UltimateDefrag

And then I disconnected it and using the same way connected the 18TB- but it assumed the letter assigned to the 16TB. I went back and forth more than once to be sure this was indeed happening, refreshing list of volumes and using not only [closed and re-opened] FreeCommander but also Windows Explorer to check this out. At some point I could no longer enter the 18TB: it showed no capacity but only its name and [the wrong] letter. So I reset the system - and during boot the chkdsk have run itself on the 18TB
[Second - the current state:]

After entering the system the letter on 18TB was still the same as for 16TB. The access to it was given back and it had now new hidden folder named found.000 holding 400+ GB of folders and files with original names preceded with e.g.

CA300000- 35300000- 14300000-

This found.000 folder I can only open when I run FreeCommander as an Administrator.

Also some folders and files from normal / old folders on 18TB are inaccessible while some old folders are empty [which were not prior to now]

[The question:]

So how do automatically move back content of that found.000 folder to its original locations?

It has almost 1000 items and [as I archive everything in folders with dates] recurring [original] names of sub-folders and files- so I have no way of knowing which had been stored within what path

 

[popatim]

Supposedly you cannot. Those are file fragments and not the full files.
But several people I know had good experiences with http://www.techcrawler.de/dechk/index_en.html in thepast. I dont know if this works under newer versions of Windows.

 

[The Electro Machine]

Is there at least a way to know which folders have disappeared and / or have missing data and / or are still inaccessible? So that I could at least know which of the backups are now incomplete - and maybe be able to get them replenished by getting the missing items to them from that other archive drive [with skipping the ones which are still present?

It is humanly impossible to check manually tens of thousands of folders. And some of my backups are exclusive, i.e. they are only on one of the drives

 

[SkyNetRising]

Is there at least a way to know which folders have disappeared and / or have missing data and / or are still inaccessible?

Chkdsk generates Event log entry. You can find some information about performed file recovery operations there.

 

[The Electro Machine]

Chkdsk generates Event log entry. You can find some information about performed file recovery operations there.

Well, under

Event Viewer > Windows Logs > Application > Wininit

I have only 4 Event IDs, all with 1001 value [and none with 1002]

And only one of them was from the day of the loss. It reads

Checking file system on X:
The type of the file system is NTFS.
Volume label is Archive OFFline16.

One of your disks needs to be checked for consistency. You
may cancel the disk check, but it is strongly recommended
that you continue.
Windows will now check the disk.

Stage 1: Examining basic file system structure ...
Attribute record of type 0x80 and instance tag 0x3 is cross linked
starting at 0x19864 for possibly 0xd clusters.
Some clusters occupied by attribute of type 0x80 and instance tag 0x3
in file 0x37e is already in use.
Deleting corrupt attribute record (0x80, "")
from file record segment 0x37E.
Attribute record of type 0xa0 and instance tag 0x3 is cross linked

[...]

Attribute record of type 0x80 and instance tag 0x3 is cross linked
starting at 0x1a7cf for possibly 0x3c clusters.
Some clusters occupied by attribute of type 0x80 and instance tag 0x3
in file 0x634 is already in use.
Deleting corrupt attribute record (0x80, "")
from file record segment 0x634.
Attribute record of type 0x80 and instance tag 0x3 is cross linked
starting at 0x1a80b for possibly 0x88 clusters.
Some clusters occupied by attribute of type 0x80 and instance tag 0x3
in file 0x635 is already in use.
Deleting corrupt attribute record (0x80, "")
from file record segment 0x635.
Attribute record of type 0x80 and instance tag 0x3 is cross linked
st

which tells me nothing - but is also described as

<TimeCreated SystemTime="2023-04-23T19:52:55.5133558Z" />

but which time [19:52] was a ~1.5 hour before the reset of system. So where is the log from chkdsk doing its work by itself before boot-up? And from test of the 16TB drive done by me before it? And from that test of 18TB ordered by me after regaining access?

From that last one I had saved to TXT file what I saw in the CMD window, which was:

Stage 1: Examining basic file system structure ...
3938048 file records processed.
File verification completed.
Phase duration (File record verification): 19.62 seconds.
11 large file records processed.
Phase duration (Orphan file record recovery): 0.00 milliseconds.
0 bad file records processed.
Phase duration (Bad file record checking): 0.20 milliseconds.

Stage 2: Examining file name linkage ...
2 reparse records processed.
4762502 index entries processed.
Index verification completed.
Phase duration (Index verification): 9.04 minutes.
0 unindexed files scanned.
Phase duration (Orphan reconnection): 39.99 seconds.
0 unindexed files recovered to lost and found.
Phase duration (Orphan recovery to lost and found): 1.32 milliseconds.
2 reparse records processed.
Phase duration (Reparse point and Object ID verification): 9.17 milliseconds.

Stage 3: Examining security descriptors ...
Security descriptor verification completed.
Phase duration (Security descriptor verification): 26.27 milliseconds.
412228 data files processed.
Phase duration (Data attribute verification): 0.55 milliseconds.
CHKDSK is verifying Usn Journal...
79256 USN bytes processed.
Usn Journal verification completed.
Phase duration (USN journal verification): 6.35 milliseconds.

Windows has scanned the file system and found no problems.
No further action is required.

17166317 MB total disk space.
9574854 MB in 2927724 files.
6075648 KB in 412229 indexes.
0 KB in bad sectors.
4046911 KB in use by the system.
65536 KB occupied by the log file.
7581577 MB available on disk.

65536 bytes in each allocation unit.
274661087 total allocation units on disk.
121305247 allocation units available on disk.
Total duration: 10.04 minutes (602473 ms).

which also does not help me a bit

 

[The Electro Machine]

[...]http://www.techcrawler.de/dechk/index_en.html in thepast. I dont know if this works under newer versions of Windows.

Unfortunately it did nothing for me

 

[The Electro Machine]

Despite asking around in other places I was unable to swiftly restore content of that found.000 folder - thus I decided to delete it. [But it was not easy as I was only able to do it using freeware FastCopy and it took a pofoundly long to do so]


This topic can now be closed