Windows reporting file system errors... chkdsk not finding/fixing them.

[Metasyntactic]

Hi All!

New STH users here. Hopefully i'm not in the wrong place to ask this question. I'm running into an oddity i've never seen before with Windows and FS corruption issues.

On my drive (storage-spaces, 16 drives, ~256 large, with 155TB used) i have a few files (around 7) where there seems to be some sort of file system corruption. Trying to do *anything* with these files gives the following error:



This includes renaming, deleting, looking at security/permissions, etc *all* fail with this message. I've been using Windows for 30+ years, and have def occasionally run into a FS issue. However, in hte past, chkdsk was always able to deal with this. However, in my case, when i run chkdsk, i get a clean bill of health:

Stage 1: Examining basic file system structure ...
  588032 file records processed.
File verification completed.
 Phase duration (File record verification): 2.88 minutes.
  520874 large file records processed.
 Phase duration (Orphan file record recovery): 115.27 milliseconds.
  0 bad file records processed.
 Phase duration (Bad file record checking): 0.16 milliseconds.

Stage 2: Examining file name linkage ...
  950 reparse records processed.
  612804 index entries processed.
Index verification completed.
 Phase duration (Index verification): 53.34 seconds.
  0 unindexed files scanned.
 Phase duration (Orphan reconnection): 62.28 milliseconds.
  0 unindexed files recovered to lost and found.
 Phase duration (Orphan recovery to lost and found): 0.15 milliseconds.
  950 reparse records processed.
 Phase duration (Reparse point and Object ID verification): 3.27 milliseconds.

Stage 3: Examining security descriptors ...
Security descriptor verification completed.
 Phase duration (Security descriptor verification): 33.51 milliseconds.
  12386 data files processed.
 Phase duration (Data attribute verification): 0.29 milliseconds.

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

 267387261 MB total disk space.
 121166748 MB in 47292 files.
    395584 KB in 12388 indexes.
         0 KB in bad sectors.
   2141811 KB in use by the system.
     65536 KB occupied by the log file.
 146218035 MB available on disk.

     65536 bytes in each allocation unit.
4278196183 total allocation units on disk.
2339488560 allocation units available on disk.
Total duration: 3.78 minutes (226881 ms).

I'm a little lost as to what to do now. Any suggestions would be appreciated. Thanks!

 

[CyklonDX]

is this refs?

 

[Metasyntactic]

Nope. Just ntfs. Thanks!

 

[CyklonDX]

I presume win11?
Is it in raid? software? windows dynamic disk?

You can be hitting some imaginary partition limits in consumer desktop windows
(I think the non-server system supports max of 256TB total for ntfs)

Have you tried booting from linux and removing those files, or command line? (is it hanging for a while, while it tries to remove the file? or throws this error right away?)

I think your best option if you want to keep using windows to move to refs for large storage, and use refs raid options instead of windows dynamic disks etc.

 

[i386]

(I think the non-server system supports max of 256TB total for ntfs)

windows 10 1809 and newer support chunk sizes up to 2MB and partitions beyond 256TB

 

[CyklonDX]

windows 10 1809 and newer support chunk sizes up to 2MB and partitions beyond 256TB

if partition was created on 1809 or newer

 

[Metasyntactic]

> You can be hitting some imaginary partition limits in consumer desktop windows

These aren't limits afaict. It's not saying I can't write any more, or that some config is wrong. It's very specifically stating that seven files (out of a massive number on this partition) are corrupt.

 

[Metasyntactic]

> is it hanging for a while, while it tries to remove the file? or throws this error right away?)

It's immediate.

 

[Metasyntactic]

> I think your best option if you want to keep using windows to move to refs for large storage,

I don't really see how that would address anything here. The issue is fs corruption and how to fix it.

 

[i386]

(storage-spaces, 16 drives, ~256 large, with 155TB used)

Did you use a command to override the ups/system is protected by a battery setting for storage spaces?

 

[Metasyntactic]

> Did you use a command to override the ups/system is protected by a battery setting for storage spaces?

Yes. The machine has a ups. There haven't been any unclean shutdowns as far as i can tell. It only goes down for semi-routine WUs.

 

[CyklonDX]

It's immediate.

then its not corruption.

 

[Metasyntactic]

> then its not corruption.

Then what is it?

All it says is "the file or directory is corrupted and unreadable". How do i find out what is causing that if it's not corruption? And how would i fix it if chkdsk isn't resolving it? Tnx.

 

[gregsachs]

Look in event viewer, windows logs, system, for errors like this:

 

[CyklonDX]

> then its not corruption.

Then what is it?

All it says is "the file or directory is corrupted and unreadable". How do i find out what is causing that if it's not corruption? And how would i fix it if chkdsk isn't resolving it? Tnx.

(a bad block, fs corruption would cause a process blocking - you would feel it - and you should know that from your own experience)


Try removing file from linux live disk, i would recommend shrinking your fs as much as you can, creating another partition - maybe refs? - moving all your data there, and expanding as you go (it will solve your issue).

You are likely hitting some imaginary wall. Could be folder path depth, too many characters and many other things.

 

[Metasyntactic]

Have talked to the NTFS team about this. They have confirmed it is a bug in chkdsk. There is corruption in my ntfs metadata in some of the alternate streams of the file. The corruption is detected, but chkdsk doesn't know about this particular case and doesn't fix it. They are going to work on a fix which will hopefully be in an upcoming version of windows.

 

[CyklonDX]

upcoming version of windows.

good luck - maybe win12 will have it fixed

 

[gea]

In the end, only ReFS will be able to find and repair corrupted datablocks as this requires data/metadata checksums.
So let's hope for ReFS on any Windows (or a stable ZFS on Windows)