TC treats built-in directory junctions differently than mklink /J ones

[ono]

Hi, I observe some TC behavior I cannot find explanation for. Each W10 user account comes with some built-in Junctions such as:

Code: Select all

dir /a
...
08/28/2020  11:50 AM    <JUNCTION>     SendTo [C:\Users\user\AppData\Roaming\Microsoft\Windows\SendTo]
08/28/2020  11:50 AM    <JUNCTION>     Start Menu [C:\Users\user\AppData\Roaming\Microsoft\Windows\Start Menu]
08/28/2020  11:50 AM    <JUNCTION>     Templates [C:\Users\user\AppData\Roaming\Microsoft\Windows\Templates]

If I enter such junction from my home folder with TC then TC follows it e.g. entering SendTo makes current directory C:\Users\user\AppData\Roaming\Microsoft\Windows\SendTo, so TC follows the target changing CWD to target of the junction.

However if I create such junction myself e.g. via:

Code: Select all

mklink /J SendTo2 C:\Users\user\AppData\Roaming\Microsoft\Windows\SendTo
Junction created for SendTo2 <<===>> C:\Users\user\AppData\Roaming\Microsoft\Windows\SendTo

Then entering SendTo2 my current folder becomes C:\Users\SendTo2 instead C:\Users\user\AppData\Roaming\Microsoft\Windows\SendTo when I enter SendTo.

For some reason TC behaves differently when parsing my own junction vs one that comes with user account. It looks there is some magic flag that makes Windows user account built-in SendTo junction behave differently than my own junction. But what flag? Is it documented anywhere? How can I read or set such a flag from command line? Apparently TC makes distinction between these two junctions, that look exactly the same when doing dir /a. Can anyone explain this please?

[petermad]

Then entering SendTo2 my current folder becomes C:\Users\SendTo2

I think you mean: "Then entering SendTo2 my current folder becomes C:\Users\user\SendTo2" but apart from that I can confirm your observations, but don't know the reason.

I can add that if I in Windows Explorer try to enter C:\Users\user\SendTo then I am denied access, but if I enter C:\Users\user\SendTo2 then the path when the folder is entered shows c:\Users\user\Sendto2 (just like in TC).

I thought it could have something to do with the owner of C:\Users\user\SendTo which is SYSTEM, but if I set the owner of C:\Users\user\SendTo2 to SYSTEM as well, it still behaves the same way.

[ono]

I can only guess that it may have something to do with reparse tags which is very poorly documented and probably completely not accessible from command line level, see https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-fscc/c8e77b37-3909-4fe6-a4ea-2b9d423b1ee4

I suspect the built-in junctions use some of these tags, while the ones made with mklink don't.

I can only imagine that Christian knowing TC sources can have a clue what makes account built-in junctions so special and why TC treats them differently.

[Dalai]

It's kind of funny. I can confirm your report, and although I've been using junctions for many many years, I never noticed something like this. But maybe that's because of the destination of the junctions I create, which usually point to a different volume.

Anyway, I'm curious about the explanation for this...

Regards
Dalai

[ono]

Okay I did a diff of outputs of SendTo2 created with mklink /j and SendTo via fsutil reparsePoint query and surprise surprise they are exactly the same - same Reparse Tag same Reparse Data:

Code: Select all

Reparse Tag Value : 0xa0000003
Tag value: Microsoft
Tag value: Name Surrogate
Tag value: Mount Point
Substitue Name offset: 0
Substitue Name length: 122
Print Name offset:     124
Print Name Length:     114
Substitute Name:       \??\C:\Users\user\AppData\Roaming\Microsoft\Windows\SendTo
Print Name:            C:\Users\user\AppData\Roaming\Microsoft\Windows\SendTo

Reparse Data Length: 0x000000f8 (...)

I have absolutely no idea what magic makes Total Commander treat built-in SendTo threat differently than SendTo2. Only Christian (author) knows, but this thread did not get his attention unfortunately.

[Dalai]

I don't think this has to do with how TC treats such junctions/reparse points. Try CMD for example. When, on Win7, a CMD is opened in the path %UserProfile% a dir command won't list any files in this "directory" (although it contains files as can be seen in TC). Doing this with the user-generated junction, it will list the files. The same applies to other junctions like "Application Data", "Start Menu" and so on.

Regards
Dalai

[gdpr deleted 6]

Try CMD for example. When, on Win7, a CMD is opened in the path %UserProfile% a dir command won't list any files in this "directory" (although it contains files as can be seen in TC). Doing this with the user-generated junction, it will list the files. The same applies to other junctions like "Application Data", "Start Menu" and so on.

I am on Win7 x64. Contrary to your observations, doing the following in a cmd shell

Code: Select all

C:\Users\{user}> dir SendTo

will show the content of the directory. The same holds true for "Start Menu" and "Application Data" (all three being directory junctions; the user account is a normal, unprivileged user account). Not sure why you don't see anything there...

[ghisler(Author)]

does "cd SendTo" work too?

[Dalai]

2elgonzo
Do you see files listed? All I'm getting is the message "File Not Found". It doesn't matter if it's an administrator or limited user account, German or English Win7 x64, 32-bit or 64-bit CMD.

It works in the target directory %AppData%\Microsoft\Windows\SendTo.

does "cd SendTo" work too?

cd SendTo works here, but the dir command won't list anything, neither while in the directory nor when supplying the directory as parameter (as shown in elgonzo's example).

Regards
Dalai

[ghisler(Author)]

TC follows the link when
- it cannot cd to the target directory, or cannot read its content, but
- can read the link target location

[gdpr deleted 6]

2elgonzo
Do you see files listed? All I'm getting is the message "File Not Found". It doesn't matter if it's an administrator or limited user account, German or English Win7 x64, 32-bit or 64-bit CMD.

Yeah, all the files (there is no difference between what TC shows and the directory listing in CMD). Weird. I don't know how you started cmd.exe, but it might be worth a shot to check in the task manager process tab under which user account cmd.exe is running. Otherwise i am clueless about what is going on there on your machine.

[Dalai]

2elgonzo
I tested this on three different systems, two of them are VMs. It doesn't matter how CMD is started - Quick Launch, TC or Windows start menu. CMD is always running under the account that's logged on (admin or limited user). In all cases, the result is exactly the same.

Regards
Dalai

[gdpr deleted 6]

2dalai

Using a VM with a normal freash unaltered Win7 installation, i was finally able to also make the same observations like you. Something is different on my box. So i compared the ACL of the SendTo junction on this default Win7 installation in the VM with the ACL of the SendTo junction on my system. And the difference became immediately apparent:

On a normal Windows installations, those junctions like "SendTo", "Application Data", "Start Menu", etc... have a particular rule set:

Code: Select all

Object: Everyone, DENY List folder/read data, this folder only, not inherited

The same ACL rule that is also responsible for the effect described by the OP.
(Although i don't know when and under which circumstances the ACL of those junctions has been changed on my machine. Better to add that rule back...)

[petermad]

Hmm,
From a DOS-prompt I can do CD Sendto when in C:\Users\UserName\, but once in C:\Users\UserName\Sendto the DIR command results in "File not found"
In Windows Explorer I can NOT enter C:\Users\UserName\Sendto, I get an "Access denied"

[umbra]

This has been discussed here a few times in the past already. E.g. https://www.ghisler.ch/board/viewtopic.php?f=16&t=25156&p=194620#p194620
That's why ghisler wrote

TC follows the link when
- it cannot cd to the target directory, or cannot read its content, but
- can read the link target location

In short, no one should be using these links today. They only exist because there are too many old, broken applications, that do not ask the OS for the correct paths, but have them hardcoded. But since the folders don't exist anymore, Microsoft recreated those paths with links, but configured them to be as limited as possible. Hoping, that developers/users who would try to use them today, would notice that there is something wrong with them.

MS documentation: https://docs.microsoft.com/en-us/windows/win32/vss/junction-points
BTW, if you copy such junction, the copy may not behave the same as the original: https://www.ghisler.ch/board/viewtopic.php?f=16&t=50876