Bug with SyncChangeDirs and junctions

[wanderer]

It's a little strange because i remember i had not changed the names of that folder (local or network) so there shouldn't have been a problem.

Hi Christian.

Finally found some time to check things. It seems i remembered correctly. Everything seemed proper and the "cd" should have worked, but... Windows Explorer (WE) shed some light into the situation.

When i tried to open the network SymLink from WE (\\....\_LinkTest_\Links\TestFolder2), i received the following message: "The symbolic link cannot be followed because its type is disabled."

I searched around and found the answer in this link. Indeed it was disabled (remote to local).

Code: Select all

C:\fsutil behavior query SymlinkEvaluation
Local to local symbolic links are enabled.
Local to remote symbolic links are enabled.
Remote to local symbolic links are disabled.
Remote to remote symbolic links are disabled.

So, it seems that TC is working fine in this case, it would be helpful though if the same message shown in WE, was shown in TC too.

[ghisler(Author)]

Thanks for your feedback!

Btw, enabling remote to local symbolic links isn't a good idea. Why? Here is an example:
1. On the remote server, there is a symbolic link named c:\link pointing to c:\destination
2. On the local PC, the user accesses \\remoteserver\drivec and sees "link" and "destination"
3. The user tries to open \\remoteserver\drivec\link
4. Since "link" points to "c:\destination", the system would try to read the local "c:\destination" directory and not "\\remoteserver\drivec\destination"

This problem does not exist with hard links (junction) because the junction isn't just a file storing "c:\destination". Instead, the junction points directly to the data of "c:\destination". Therefore it also works remotely.