Why many ntfs directory entries corrupt to 0 bytes size

Question

Large Seagate "Expansion" usb3.0 multi-terabyte drive.

Periodically moves physically between two W10P machines. Both machines standalone and WSUS up-to-date.
In use for a couple of years. is now at 90% capacity. drive originally setup/formatted on wkstn1. The problem occurs when re-connecting the drive to Wkstn1.
The problem first happened at about 80% capacity about 6 months ago. It hasn't occurred every time the drive is removed/replaced.

In normal use, hundreds of files may be added or deleted to the drive in either location.

0-byte entries are concentrated in the most recent file entries. over time files are categorized into sub-folders. Anecdotally I've noticed corruption in the subs too
but haven't proved a relation to the subject of this post. Again,anecdotally its possible entries are disappearing completely from the NTFS.
The corruption only occurs on the external drive. There's no problem outwardly visible during normal usage of either machine.

I thought that rebuilding WSearch indexes before using the drive after a move would help. Not any obvious help, maybe its part of the cause? The location of the indexes
is currently on the local C: drive of each wkstn. If I remember correctly, the instantiation of the observable problem started with noticing searches that were empty but obviously shouldn't be.

Most recent episode. connected the exp drive to the wkstn1 prior to power up. Power up. Before Windows login (and before the pre-login window turns blue). I
got a large(er) text status line toward the bottom of the display about "Fixing...Stage #. Scanning and reparing drive (D:): n% complete"

Sorry I didn't track any possible earlier messages, nor did I think to copy down the status as it happened. The above is from memory. I recall there
were 3 stages. the 2nd to last "stage" had numbers eg: "777000 of 825000" and the last stage something like "863 of 1800"
The entire "scan/repair" process took a few minutes and all stages reported nothing beyond their completion.

I did find this in the system eventlog:
Volume D: (\Device\HarddiskVolume9) needs to be taken offline to perform a Full Chkdsk. Please run "CHKDSK /F" locally via the command line, or run "REPAIR-VOLUME <drive:>" locally or remotely via PowerShell.

Did it run chkdsk by itself?

I get the feeling there's just a disconnect between the FileExp/NTFS directory info and the on-disk actuality (ie fe/ntfs is confused and if i could repair that I might
find that the 0-byters are back to robust.) But if chkdsk was what I saw running, the damage is done no?

Checking properties of individual files: the text: "this file came from another computer and might be blocked to help protect this computer."
appears on many entries. I thought only the 0-byters have it (every 0-byter I checked does have it). But the same message appears on non-corrupted files too.
And it appears on non-corrupted files that _didn't come from the other machine.

Seagate's Seatools is pretty much useless and reports "Passed". Seagate also may have some sort of "manager" but I haven't been able to find it for download. I'd hoped if I did
it might have a rebuild directory entries/recover option of some sort.

I'm willing to try a 3rd party tool. One that will actually recover the link between directory entry and data. Don't know if recommendations are allowed on this site, but I'm willing to look if you can provide.

thanks for reading and any help/ideas you can offer. my curiosity is equal to my frustration at this point.