Bug with SyncChangeDirs and junctions

[wanderer]

Here's the situation. I'm currently transferring data from a disk on a PC (A) to another disk on another PC (B). Under one of the relatively top-level folders, a junction exists which points to another folder, in the same drive but much deeper in the tree. I copied this folder, so (due to TC configuration) instead of copying the junction as a folder, it just created the junction (the destination folder still has not been copied though).

In wincmd.ini, i have the following setting:

Code: Select all

SyncChangeDirMode=5

Now, i enabled SyncChangeDirs from a toolbar button, and tried to enter inside the junction of PC B. Since the destination folder does not exist yet, TC beeped but in the other folder (of PC A) in enter in it. At the same time, the relative SyncChangeDirs button in the taskbar got a pause mark on it. When i returned back, it should have gone, but it didn't.

I understand that it can be complex to handle such situations so there is no problem in the way TC behaved, but my question is the following (mainly to Christian): Is the SyncChangeDirs procedure expected to handle these types of situations in a more proper way (remember the "base" paths and remove the pause mark from the button when going back, even if it had failed to CD in one of the two folders)? If yes, then i'm reporting it has failed.

[ghisler(Author)]

I cannot reproduce that. Junctions to directories work the same here as directories when using SyncChangeDirMode=5.
Maybe it's the way how you turned back? I tried
- Enter on [..]
- Alt+Backspace
- Ctrl+PageUp
- Via history
With all of them SyncChangeDirs resumed (pause icon disappeared).

[wanderer]

OK, here are some more tests i've performed and their results:

Left panel
A network drive. At its root, there's a folder Test1 and in it a junction named Test1-1. Its destination is in the same drive but has not been copied yet, so it does not exist.

Right panel
A local drive. At its root, there's a folder Test1 and in it a junction named Test1-1. Its destination is in the same drive and it exists.

Being at the root of both drives, i enable SyncChangeDirs. Double-clicking on Test1, cd's successfully in both panels. Now the interesting part:

1. Double-clicking on Test1-1 in the left panel results in entering Test1-1 in the right panel but the left remains there (since the junction destination does not exist). The SyncChangeDirs toolbar button has remained normal (without a "pause" indicator). Going to the right panel and clicking on the ".." inside the panel (or the ".." button), results in the directory of the right panel going upwards 1 level but now the SyncChangeDirs toolbar button has a "pause" indicator on it.

2. Double-clicking on Test1-1 in the right panel results in entering Test1-1 in the right panel but the left remains there (since the junction destination does not exist). The SyncChangeDirs toolbar button has been updated with a "pause" indicator on it. Going to the right panel and clicking on the ".." inside the panel (or the ".." button), results in the directory of the right panel going upwards 1 level but the SyncChangeDirs toolbar button still has a "pause" indicator on it.

The bold parts in both cases is a bug. When going into Test1-1, the "pause" indicator should have appeared and when going up one level, it should have been removed.

P.S.: Tests were performed with the newly-released 11.03RC3 x64 under Win10.

[ghisler(Author)]

Thanks for the detailed description, I can reproduce it now. I misunderstood you first, I thought that there was a missing junction in the target panel, not that the junction in the source panel would point to a non-existing directory.

[wanderer]

Yup, seems to work properly in RC4. Thanks.

EDIT: Wrong! There is another bug now. See next post!

[wanderer]

OK, the SyncChangeDir function works properly but there is a strange side-effect now.

Left panel
A network drive. At its root, there's a folder Test1 and in it two junctions named Test1-1 and Test1-2. Their destinations exist.

Right panel
A local drive. At its root, there's a folder Test1 and in it two junctions named Test1-1 and Test1-2. Their destinations exist.

Enable SyncChangeDir, traverse all folders with SyncChangeDir enabled, it works just fine. Now, rename the destination of the junction Test1-1 in the left panel (network drive).

SyncChangeDir is still enabled. Enter folder Test1-1 (double-click on it in the right panel). You will see that it enters into it only in the right panel, the left remains where it is and SyncChangeDir button is "paused". Now doubleclick on the "..", you are returned back and SyncChangeDir is "unpaused" again. Now, enter folder Test1-2 and return back (".."). SyncChangeDir is OK but folder Test1-1 is now not shown in the left panel! If you rename its destination to the original name and repeat the "go into Test1-2 and back" procedure, it appears again (after pressing F2 to refresh).

[ghisler(Author)]

I don't understand your report. What do you mean that folder Test1-1 is now not shown? According to your report, Test1-1 is a junction and not a folder?

[AntonyD]

2wanderer
Yes, indeed - for a such complex reports it would be much better or supply it with video - or with a bunch of photos.

[wanderer]

OK, what i described happens with SyncChangeDirs enabled between a local and a network drive. In the text below step-by-step instructions are shown, assuming you have 2 PCs available.

- In each PC, execute the batch file shown at the end of this post.
- In PC2, goto drive C: (in TC or explorer), rightclick, select Properties and then Sharing.
- Go to Advanced Sharing and share the drive with a name (for instance PC2C)
- Go to PC1
- Open TC
- At the left panel, cd to \\PC2\PC2C
- At the right panel, be in local C:
- Enable SyncChangeDirs via a buttonbar button.
- Doubleclick on "_LinkTest_" at the right panel
- Doubleclick on "Links" at the right panel
- Doubleclick on "TestFolder1" at the right panel. So far, as you will see, TC changes dirs in both panels normally.
- Doubleclick on ".." at the right panel. You are now in folder "_LinkTest_\Links" in both panels.
- Now, in PC2, go to "C:\_LinkTest_\Folders\TestFolder1" and rename it to "TestFolder1a". This is the destination folder of junction "Links\TestFolder1" in PC2.
- In PC1 again, in the right panel (local drive), cd to "TestFolder1" again. You will now see that the left panel has remained in "_LinkTest_\Links", since the destination of the juction does not exist. The buttonbar button is correctly in Pause state.
- Doubleclick on ".." at the right panel. You are now in folder "_LinkTest_\Links" in both panels and the buttonbar button has correctly returned to Unpaused state.
- Now doubleclick on TestFolder2 at the right panel. All is normal so far.
- Doubleclick on ".." at the right panel again. You are now again in folder "_LinkTest_\Links" in both panels, but in the right panel junction "TestFolder1" is shown, in the left it has disappeared though!

Code: Select all

@echo off
C:
cd \
mkdir _LinkTest_
cd _LinkTest_

mkdir Folders
cd Folders
mkdir TestFolder1
mkdir TestFolder2

cd ..

mkdir Links
cd Links
echo Creating a Junction to TestFolder1...
mklink /J TestFolder1 C:\_LinkTest_\Folders\TestFolder1
echo Creating a SymLink to TestFolder2...
mklink /D TestFolder2 C:\_LinkTest_\Folders\TestFolder2

If this is still unclear, i'll try to create some kind of video at a later time.

[ghisler(Author)]

This does not seem to be a Total Commander bug: When I open Explorer after "Links\TestFolder1" disappeared in Total Commander, it will be invisible there too. It seems to be a feature of Windows 10 to hide links on network drives if they point nowhere. I tried the same with Windows 7 as the target, and there the phenomenon did not occur.

Once I rename the target back from "Folders\TestFolder1a" to "Folders\TestFolder1", the link does not immediately reappear. However, it appears when I create a new directory in "Links". So it seems that Windows is caching the remote directories and only re-reads them when there are certain events.

It's interesting that different events cause the link to disappear and to reappear:
1. The link only disappears when the target is gone AND I try to open the link. Then Windows 10 (remote) notices it and hides the link.
2. The link reappears when I modify something else in the directory, e.g. create or rename a file or folder. Strangely the link reappears even when the target is still gone.

Something similar happens in the Explorer: When I double click there on "Links\TestFolder1", I get an error message. When I then press F5, the link disappears. Then when I create a new folder AND press F5, the link reappears too.

[ghisler(Author)]

The disappearing link seems to be a Windows feature, so no change here.

But I fixed another bug in RC5, please check it:

cm_SyncChangeDir: Handle another special case where the directory didn't exist in the target panel (or couldn't be changed), and couldn't be changed in the source panel either (e.g. junction pointing nowhere, or insufficient access rights): keep cm_SyncChangeDir enabled (32/64)

[wanderer]

OK, indeed there is a change from RC4 to RC5. In RC4, the button turned to "pause" when both the source and destination folders could not be "entered". This is better in RC5, no "pause" on the button (which seems more logical).

I've discovered something else though, which happens in both RC4 and RC5. Here are steps to reproduce it:

- Under "Folders", rename "TestFolder1" to "TestFolder1a" in one path only (local / network doesn't seem to matter but let's rename the net path only).
- Enter "Links" folder in both panels.
- Enable SyncChangeDirs.
- Try to cd to TestFolder1 in the local panel (doubleclick on it). A beep is heard and only the local folder is entered.
- Now return back to "Links (in the local panel) and try to cd to TestFolder2 (in the local panel again). Even though the destination folders exist in both sides, a beep is heard and the source panel changes to "TestFolder2" but the destination doesn't.

[ghisler(Author)]

Your last case has nothing to do with renaming "TestFolder1" to "TestFolder1a":
The link to "TestFolder2" was created with mklink /D, so it is a symbolic link.
As explained for example on superuser.com, you cannot follow symbolic links on a network share because they are always resolved in the context of the local system. Therefore the remote PC cannot follow the link.
"TestFolder1" was created with mklink /J, so it is a junction. Junctions do not store a target directory, they directly point to the data of the target directory. Therefore they also work remotely, because no target needs to be resolved.

At least here I cannot open Links\TestFolder2 on the share at all, even when I freshly start cm_SyncChangeDirs with the Links folder on both sides.
Can you enter TestFolder2 on the remote share?

Btw, if I start an elevated cmd shell (as administrator) and issue the command

Code: Select all

fsutil behavior set symlinkevaluation R2L:1

then double clicking on Links\TestFolder2 will follow the link, but show the content of the LOCAL directory
c:\_LinkTest_\Folders\TestFolder2
and not that of the remote directory with the same name. That's because the Windows link resolver only sees that path stored in the link, it cannot know to what share it would point on the remote server (if it is shared at all). You can query the state of the symlink resolution behaviour with

Code: Select all

fsutil behavior query symlinkevaluation

and disable remote to local via

Code: Select all

fsutil behavior set symlinkevaluation R2L:0

On Windows 10 and 11, only local to local and local to remote symlinks will be followed to avoid the above problem.

[ghisler(Author)]

Moderator message

Moved to will not be changed

[wanderer]

The link to "TestFolder2" was created with mklink /D, so it is a symbolic link.
As explained for example on superuser.com, you cannot follow symbolic links on a network share because they are always resolved in the context of the local system. Therefore the remote PC cannot follow the link.

Well, we've learned something new today... Thanks for the info.

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. Unfortunately i couldn't find the time to test it because i can only test it at work and i'm a little swamped these days, so let's leave it as is and if i find anything later on, i'll let you know.