[SOLVED] New Windows 10 is (maybe) screwing file indexes from old Windows 10

[gromenawer]

I have 3 hard drives with the following configuration:

- A: Old Windows 10 installation

- B: New Windows 10 installation

- C: Big hard drive with file dumps. Games, movies, etc...


C works perfectly fine with A. Now, I swap A with B, and everything is fine so far. I go back to A and write something new in C. When I go back to B, then the new files are not in C anymore and B has sort of "restore" the previous snapshot of C from the last time it was working with B. However, when I come back to A, the new files that were written by A, are now gone; although I can read the new files written by B in C from A.

Before I continue, clarify that I have admin rights to both A and B. The files are not hidden. The files are not in the recycle bin or whatever. However, the files are still there since the size of occupied space f the hard drive C is still the same. I can't find the files using the Linux partition either.

So, my questions are:

- What the hell Microsoft? How I'm suppose to know that this is an issue that I need to pay attention before discovering that I have losing files? Like, a totally fresh W10 install and I can't literally share a common hard drive between windows installations now? Are you going to delete my USB sticks too?

- Is there any way to recover the file indexes? I haven't actually lost anything of value since I have proper back ups. But this is completely baloney. There has to be a quick way to make A restore the old index, or whatever, and at least get C back to normal.

[Supafly]

Since it's screwy I'd try rebuilding the Index rather than trying to fix something to keeps breaking
Windows Key + S > Type Index and select Indexing Options when it appears > Advanced > Rebuld

[gromenawer]

So, restoring the index did nothing.

However! I did the option of scan + repair that is build in with windows:

- right click on G: (or whatever is your letter) -> properties -> tools -> Error checking -> Check

Then click scan, then click repair. And that fixed the issue.

Thanks for reading me and the help, hope that this save a headache from somebody else in the future.

[gromenawer]

Just to clarify, that fixed the issue that A can now read from C, I have no idea, and I will not try, to use B for the moment yet.

[↑↑↓↓←→←→BASelect]

Wow op's post read like a set of stereo instructions.

[Iceira]

Things dont work like that anymore your ID is not same in whatever other OS, this is know is server related issue and it look like same issue here.

Tecnicaly you can call it security with files not inherited on same system and 2 diffrent OS will not have same Master ID.

index made on one system cant accept other system index , thats is a security issue.


could also say you access something other system has under protection, and that mean it cant be just storage data in a share. ( this cant just be a text file or picture or video file its system data with or part of security that prevent you from have right to change it. )

[Elucidator]

That sounds like you wrote a file into cache and it didn't actually save and store on the hard drive.

Edit:
Look:
When you wrote a file with A, and tried to read it with B, the file disappeared. (its not on C)
That means that part of the system at that time wasn't actually on C
You wrote a file, and it got cached instead of 'written'.

Normally when you let windows shut down properly, the cache is emptied and the files get written to disk. (again shutdown, not sleep/hibernation)

Some service is probably enabled to cause things to cache somewhere... (cache could be a space in RAM, it could be intel opane or something else)

Whatever this is, it seems that this cache is disabled on B, because when you write something with B, it still appears to be on C, when read from A or your live linux system usb.

(keep in mind usbs can be used as cache when readyboost is enabled)

[gromenawer]

Elucidator の投稿を引用：

That sounds like you wrote a file into cache and it didn't actually save and store on the hard drive.

Edit:
Look:
When you wrote a file with A, and tried to read it with B, the file disappeared. (its not on C)
That means that part of the system at that time wasn't actually on C
You wrote a file, and it got cached instead of 'written'.

Normally when you let windows shut down properly, the cache is emptied and the files get written to disk. (again shutdown, not sleep/hibernation)

Some service is probably enabled to cause things to cache somewhere... (cache could be a space in RAM, it could be intel opane or something else)

Whatever this is, it seems that this cache is disabled on B, because when you write something with B, it still appears to be on C, when read from A or your live linux system usb.

(keep in mind usbs can be used as cache when readyboost is enabled)

This sound very plausible, specially the sleep/shut down part.

I remember having to set manually for W10 to shut down because it doesn't. It goes to sleep by default even though you click "power off" (or whatever is called). And I also remember that updates revert that option back.

Honestly, W10 is such a headache in this regard. I dread W11 already. I only use Windows for gaming, and I might as well install a Steam OS in another hard drive and give it a go already. I really hope that I can ditch windows forever one day; and with the release of Steam Deck this might as well give me the final push that was needed.