Accessing remote server junctions/hardlinks

[wanderer]

In one of TC panels, go to a remote path (i.e. \\servername\C$\Users). Then navigate to \\servername\C$\Users\Default User. TC, instead of showing \\servername\C$\Users\Default User, it shows the contents of C:\Users\Default User (instead of translating the hardlink to the remote path as one might expect, it translates it to the local path).

Relevant tests have been performed between 2 Windows 2008 servers.

This behavior is not necessary incorrect but IMO in some cases it would be more logical to try to translate the hardlink to the remote path before just CDing to it. Perhaps there could be an option for this behavior: 1: try to translate remote hardlinks to local paths (as works now), 2: try to translate remote hardlinks to remote paths only, 3: try to translate remote hardlinks to remote paths and if remote path does not exist, try local path, 4: ask the user.

[ghisler(Author)]

Is "Default user" a hard link (junction)? I guess so. Windows hard links contain an absolute path to the location on that PC, not a relative path. So TC cannot know whether it should point to local C:\Users\Default User or remote C:\Users\Default User...

[wanderer]

Is "Default user" a hard link (junction)? I guess so.

I can't check it at the moment but 99.9% yes. TC displays a "shortcut" icon instead of a "folder" one, so...

Windows hard links contain an absolute path to the location on that PC, not a relative path. So TC cannot know whether it should point to local C:\Users\Default User or remote C:\Users\Default User...

As i said,

This behavior is not necessary incorrect

but if one is accessing \\server1\c$, it would be more logical for a junction to lead to the relevant folder in server1 than to the same folder in the local pc. After all, AFAICR junctions do not support network destinations, right? So, most probably the intended destination of the junction would be in server1 and not in the local pc.

Anyway, if you feel it's more proper as it works now, could you at least add an ini-config option to make it point to the destination server folder? I know, it won't always work because users may not always have access to \\server1\c$ in order to reroute to the proper folder but in that case a beep or an error could appear.

I first noticed this issue having cm_SyncChangeDir enabled between a local and a remote 2008 server. You can imagine my surprise when at some point both TC panels showed the same dir and i couldn't understand how this had happened (at first).

[ghisler(Author)]

The problem is that there may be situations where it makes sense to let the junction point to a different drive.

For example, I use junctions on my eee PC which has a small 4GB c: drive to relocate some rarely used Windows folders to a different, larger drive. Also it could be used on network drives to point to a user's home directory on the local harddisk.

So what should be done? Should I show a warning? Ignore links pointing to other drives?

[HolgerK]

So what should be done?

Create an option to not to traverse these links if under special permissions "List folders/read data" is set to "deny" for everyone.

At least this is the behavior of Windows Explorer:

[Window Title]
Network Error

[Main Instruction]
Windows cannot access \\SERVERNAME\c$\Users\Default User

[Content]
Check the spelling of the name. Otherwise, there might be a problem with your network. To try to identify and resolve network problems, click Diagnose.

[^] Hide details [Diagnose] [Cancel]

[Expanded Information]
Error code: 0x80070005
Access is denied.

Regards
Holger

[wanderer]

So what should be done? Should I show a warning? Ignore links pointing to other drives?

As i proposed in my first post, make it configurable (by "option" i mean INI setting):

This behavior is not necessary incorrect but IMO in some cases it would be more logical to try to translate the hardlink to the remote path before just CDing to it. Perhaps there could be an option for this behavior: 1: try to translate remote hardlinks to local paths (as works now), 2: try to translate remote hardlinks to remote paths only, 3: try to translate remote hardlinks to remote paths and if remote path does not exist, try local path, 4: ask the user.

Maybe option 3 (if implemented) should also show a warning when remote path cannot be accessed and local path is used instead. Options 1 2 and 4 seem enough though.

[MVV]

Also it could be used on network drives to point to a user's home directory on the local harddisk.

BTW junction may exist only on NTFS drive and may point only to folder on NTFS drive - so it won't work through network (symlinks may be used for that however). So I agree with users who say that it is more logical to redirect to network shared drive C$ instead of local drive C: (or show an error if drive is not accessible). Hm-m, what Windows does with such links on network drives?

[wanderer]

and may point only to folder on NTFS drive

I thought of that too but when i thought some more of what Christian said, it seems there's a workaround for creating network junctions (well, sort-of, it's not an actual network junction).

Example: You have a folder C:\Test\1\2\3\4 on your PC. You can create the same folder in a remote PC, create a junction "C:\JTest" in the remote PC to point to its local C:\Test\1\2\3\4. Now, in your local PC, if you go to \\remotepc\c$\JTest it will redirect you to your local C:\Test\1\2\3\4. I can understand that this can be very convenient in some cases but it just doesn't seem logical.

[MVV]

You may try to test it with Windows Explorer. I don't think Windows will allow such things. It is only TC feature to read target paths from junctions/symlinks and to change dir according to theese paths if change dir to folder fails.

[wanderer]

This one is partly solved in TC 7.56. If you try to press enter on a junction located on a network location, you get an "access denied" error, however if you press CTRL + Arrow (left or right, depending on the active TC panel), the folder is opened in the other panel but without showing any contents. If you try to copy a file to the empty folder though, the file is correctly being copied into it.

IMO pressing CTRL + Arrow should display the same "access denied" error as if pressing ENTER on the folder.