How to restore the ability to synchronize between OneDrive and Yandex.Disk?

Question

Yandex.Disk

There was a problem after updating Windows 10 to 1709. There is the following configuration. Work machine (W) with a large drive, on which the files are located (Let it be \W with folders \W\1\*.*; \W\2\*.*). There is a OneDrive folder on this machine that contains symbolic links (symbolic link (folder)) to folders with these files (W\OneDrive\~\1\*.*; W\OneDrive\~\2\*.* etc. .).
There is a second machine (\R) that has a \OneDrive folder synced with the first (W\) (i.e. R\OneDrive\1\*.* folders; R\OneDrive\2\*.* folders, etc.) correspond to folders (W\OneDrive\~\1\*.*; W\OneDrive\~\2\*.*, etc.) Yandex.Disk (application) is also installed on it and in its folder \ YandexDisk made symlinks from the OneDrive folder (R\YandexDisk\~\1\*.*; R\YandexDisk\~\2\*.* etc.).
External employees often work on older versions of Windows, so it was not possible to install OneDrive for seamless collaboration for everyone. Everyone works together by invitations to folders on Yandex.Disk. In addition, OneDrive does not work with symlinks (the official answer from MS), more precisely, when a file is changed, it is not updated - files located on symlinks are scanned only when OneDrive is first launched. The established scheme made it possible to have synchronous copies, provided that the machine W and R were running.
Until Friday the 13th, everything was fine, the system worked like clockwork, and the project coordinator (R) saw who and what changed because Yandex.Disk sent notifications to him, but in the evening an update rolled up and OneDrive has now become even more beautiful, with blackjack and everything else (became for example, show some unnecessary "status" for each element).
But Yandex.Disk now gives an error on these symlinks.
An attempt to roll back to the working configuration (to Win 10 1703) led to the fact that Yandex.Disk generally perceived the symlinks as deleted and deleted the corresponding folders in the cloud.
Having re-rolled the update, we got a situation where Yandex.Disk gives an error, but sees the files on the links. But another misfortune arose, now Yandex.Disk endlessly updates these files in the cloud, and behind it OneDrive also starts updating them and the process goes around in circles without stopping. At the same time, all files that fall under the distribution are marked with the current date, destroying the current control :(
To minimize the damage, Yandex.Disk is disabled for now, but there is no longer enough imagination how to organize the work now. Advice is needed :(
PS: Yandex.Disk is also installed on machine W, but it works for a separate folder that is not related to OneDrive, because in addition to the linked folders in Yandex.Disk, there are also folders with collaboration, i.e. there are duplicates of problematic folders on W.
PPS: machine W works 24/365 and machine R only during business hours.

Answer 1

Kulver_stukas ,

I tried Directoty junction (/j) and Symbolic link (/d) in FARe, no difference.

There is. Just eat.
I have a feeling that there are some kind of symlinks on symlinks. I have no idea where and who taught you to "draw" diagrams, but what you wrote - suggests a diagnosis :P.
If the folders are "synchronized", then perhaps you should not re-describe "how"? The word itself already captures the essence. It is necessary to explain only if the contents of different folders are synchronized.
Due to problems with updating OneDrive and the fact that everyone works through Ya.Disk anyway, maybe this OneDrive is in the ass, just go to Ya.Disk.
I also had similar linking schemes, between Ya.Disk, Google.Disk and Mega, and even schemes indicating one folder for different programs, but due to frequent problems with similar consequences, the synchronizer stops seeing updates, then it starts endlessly download (although I have not seen a cyclic update). Therefore, I did it differently: in Ya.Disk - there is a symbolic link to the folder with the necessary "documents" (there were never any problems), copies of these files are manually placed in a special Google.Disk folder (links to these files were sometimes buggy), and this special folder is indicated by one of the folders for the Mega client (here the links did not work at all, but I have not checked for a long time).
Actually, the same thing can be done in any of the programs (or in all), it is not clear why a link to a link is needed and the link drives, especially when there is a double "reference". I divided it into manual copying just for the sake of a whim.