CHKDSK reporting "file contains too many file names" for files on the backup storage

Server
1

Sadly it’s not helpful about what files since it reports the file index and not the file name.
the reports are of the form:

Stage 1: Examining basic file system structure …
NNNNNNN file records processed.
File verification completed.
Index entries referencing file NNNNNNN will not be validated
because this file contains too many file names.

Multiple file reference numbers are involved.

The advice for even identifying the file that I’ve been able to locate isn’t helpful, particularly as the software identified isn’t available anywhere I can find (provided links dead).

One would think that fsutil file queryfilenamebyid would get the answer, but for these files it returns the parameter is incorrect

I’ve run chkdsk on the client machines (from WinPE so I could read the output) they don’t trigger this output, so the issue isn’t with the source files as far as I can tell.

2

Did this get resolved? I seem to have the same issue.

3

Not “Solved” in terms of UrBackup creating the issue, however, “Solved” on the disk itself.
I used Active@ disk editor (the free version) to track down the files involved by what CHKDSK reported.

In my case they had totally unrelated names associated, A Windows registry file & some user gernerated file.

I was under time pressure & simply used the same disk editor to delete the file(s) involved, then ran remove_unknown & created a new backup…

Conclusion:
Either something funky occasionally happens that results in UrBackup linking unrelated files, or else those SHA checksums are far les immune from collisions than the cryptographers would have us believe, I mean MUCH MUCH less immune, making md5 look secure…never mind SHA1…

I was under too much time pressure to try diagnosing which, & since suffered a bereavement which (rather) delayed my response, or fixing the (hardware failed) server involved until now…

I simply hadn’t the free time to try to track down the answer, or submit a proper bug report.

I’ve no idea if the issue still exists in the current version, I’ve still not got round to upgrading from version 2.4.13.

For all I know it’s either fixed or we’ve discovered that that SHA checksum algorithm is flawed, I’ve no idea which, but if I had to bet the issue would be with UrBackup, since no other screaming about file hashes has made security news that I’m aware of.

I now have another slew of the same CHKDSK error.

Frankly I’ve no real Idea which it is out of cryptographic hashes fundamentally broken, or else @uroni having zero idea how many names NTFS allows per file, which, to be fair I can’t find any reference to either Microsoft seem to be keeping THAT as dark secret even more than how to break Windows activation, which CAN be found by Google… UNLIKE NTFS limitations.

Now I’m running CHKDSK, it seems I have a whole slew of new instances of this error, unfortunately I’m using an old version so @uroni will have ZERO interest. As witnessed while I was using Stable & he was working on a Beta… & I Posted about it…

Sorry I cant offer any good solution, apart from using some OTHER backup software, & this is the reason this is my SECOND line of defence, rather than my primary backup solution, I’m only about to try it in the event Macrium Reflect fails in some way…

I’ve frankly reached the point I don’t completely trust UrBackup’s FILE backups, only Images.
Especially as I now have a slew of the same error… Which I’ve yet to investigate.