RealtimeSync not detecting changes through Symbolic Links

[mc-lemons]

I am syncying my Desktop to a network drive. I created a Symbolic Link to my Desktop in another folder on my C drive. I then sync that folder and it contents, which syncs my Desktop (through the Symbolic Link using the "Follow" option) to the network drive. I set this all up in a .ffs_batch file.

Running the batch file by itself for a one time sync works fine. However, when using RealtimeSync I'm having issues. There will be an initial sync when I start RealtimeSync, but then after that no other changes are detected and synced. To test and make sure that the Symbolic Link was the culprit, I created another .ffs_batch file that pointed directly to the desktop (without going through a Symbolic Link) and RealtimeSync worked great then. I tried the same test with the Documents folder and I had the same results (so its not something with just the Desktop folder).

So it appears that RealtimeSync is having issues detecting changes through Symbolic Links.

I'm running Windows 7 Pro SP1 64-bit.

I'd really appreacite any help on this. Thanks!

[Zenju]

I can confirm, RealtimeSync does not detect changes through symbolic links, which is the default behavior on Windows when monitoring the file system.

[mc-lemons]

Is there some way you can circumvent the default Windows behavior so that this is possible?

[Zenju]

There is no support from the OS to detect changes through symlinks, neither on Windows nor Linux. So the only solution could be to manually traverse the directory which shall be monitored, detect the symlinks and apply special handling. But this could be expensive for large directory trees and somewhat defeat the benefit of RTS compared to a simple recurring sync.

[monycker]

There is no support from the OS to detect changes through symlinks, neither on Windows nor Linux. So the only solution could be to manually traverse the directory which shall be monitored, detect the symlinks and apply special handling. But this could be expensive for large directory trees and somewhat defeat the benefit of RTS compared to a simple recurring sync.

Is this still the case? I have reason to believe that Microsoft has been making drastic changes to their symlink handling.

I believe a good example of this to be directory links I had previously created by using system volume GUID pathname strings via command-line syntax similar to[ mklink /d "Link" "//?/Volume{s0meRand0m-Numb3rs-4ndLe77ers}/Target"] which had worked in the immediately-most-preceding version of Windows 10 but which were suddenly rendered ineffective immediately following Windows 10 update KB4041994 when browsed via certain Windows-native file explorer windows, like that which would appear when selecting custom folder toolbars via right-clicking on the taskbar, hovering my cursor over "Toolbars", and then left-clicking to select "New Toolbar...", which has been a feature of Windows since as far back as I can remember( Windows ME, anyone?).

This has led me to believe that Microsoft has modified the framework of how their own system handles symbolic linking; I wish I had learned of this FFS caveat before learning more about symlinks, otherwise I would have stuck to customizing my .ffs_batch files a little more specifically. That said, however, I have come to enjoy the versatility of popping out symlinks in already-monitored directories to expand the inter-connectivity of resources I use in a variety of projects, and it would be a shame to think that, in order for FFS/RTS to work effectively, they would require me to have duplicate directories and files scattered across my filesystem mediums.

But IF Microsoft has indeed modified their framework enough that it would be possible for symlinks to be traversed by RTS, I would like to issue a formal feature request. This functionality would be of ENORMOUS help to me, and I can't help but feel like, in a production environment, it would be of enormous help to anyone else who uses similar resources in multiple projects.