Compatibility issue with junctions

Help & Support
1

I would like to report a possible compatibility issue with junctions created by Directory Opus.

In my environment, junctions created by Directory Opus always have a \??\ prefix in their target path. For example, dir /al shows:

<JUNCTION> 计算机组成原理 [\??\F:\book\计算机\计算机组成原理]

This junction used to work normally, but recently it can no longer be accessed by a reading application running with normal user privileges. The same application can access it when running as administrator.

The error message is:

image
image832×659 37.9 KB

The meaning of the Chinese error text in the screenshot is:

Cannot access F:\Books\计算机\计算机组成原理.

The path cannot be traversed because it contains an untrusted mount point.

For comparison, if I manually create the junction from the command line:

mklink /J "F:\Books\计算机\计算机组成原理" "F:\book\计算机\计算机组成原理"

then dir /al shows the target as:

<JUNCTION> 计算机组成原理 [F:\book\计算机\计算机组成原理]

This command-line-created junction does not have the \??\ prefix, and the same reading application can access it normally without administrator privileges.

I also noticed that directory symbolic links created by Directory Opus do not show this \??\ prefix. The prefix appears only on junctions created by Directory Opus.

Therefore, this issue seems to be related to the target path format used by Directory Opus when creating junctions. Junctions with the \??\ prefix may now be treated by some normal-privilege applications or Windows security checks as “untrusted mount points”.

I am not sure whether this started happening after a recent Windows update, because these junctions used to work normally before.

My environment:

latest updated Windows 10 22H2 x64, zh-CN
Directory Opus 13.22.11 (Beta) Build 9476 x64
OS 10.0 (B:19045 P:2 T:1) SP 0.0

Could you please check the way Directory Opus creates junctions, especially the difference compared with junctions created by mklink /J?

2

Junctions made with Opus (with \??\ prefix if listed by the dir command) work fine here, including in File Explorer. The prefix is normal/allowed.

You're on old versions of both Opus and Windows, so I would try updating both first.

3

Thanks for the reply. I understand that the \??\ prefix is a valid NT namespace prefix, and I am not saying that the junction is invalid.

The issue I am reporting is about compatibility/security behavior in normal-privilege applications.

In File Explorer, the junction does work. However, in my reading application running without administrator privileges, the junction created by Opus fails with this Windows error:

Cannot access F:\Books\计算机\计算机组成原理.

The path cannot be traversed because it contains an untrusted mount point.

If I run the same application as administrator, it works.

The important comparison is:

Opus-created junction:
<JUNCTION> 计算机组成原理 [\??\F:\book\计算机\计算机组成原理]

mklink /J-created junction:
<JUNCTION> 计算机组成原理 [F:\book\计算机\计算机组成原理]

Both point to the same target folder and have the same permissions, but only the Opus-created junction fails in that normal-privilege application.

Also, directory symbolic links created by Opus do not show the \??\ prefix in dir /al; only Opus-created junctions do.

image
image1092×209 24.3 KB

So I am not claiming that \??\ is illegal. My concern is that when the prefix appears in the junction target as listed by dir, some software or Windows security checks may treat it differently and reject traversal as an “untrusted mount point”.

Could you please use fsutil reparsepoint query "xxx" to compare the reparse point data written by Opus with the one written by mklink /J, especially the Print Name / display target? It seems mklink /J creates a junction that avoids this compatibility issue.

image
image1239×939 69.1 KB

Would it be possible for Opus to create junctions in the same format as mklink /J, or provide an option to do so?

4

Explorer and Opus don't normally have administrator privileges either.

The junctions Opus makes also work fine from a non-admin command prompt (at least with the current versions of Opus and Windows; I've not tried with Win 10 22H2).

5

See this picture:

image
image1239×939 69.1 KB

For the junction created by Opus, the Substitute Name is present:
??\E:\test_src

but the Print Name length is 0, so there is no Print Name.

For the junction created by mklink /J, the Substitute Name is also:
??\E:\test_src

but it additionally has a Print Name:
E:\test_src

So the difference does not seem to be that the NT substitute name exists; that part appears normal for junctions. The difference is that mklink /J also provides a user-facing Print Name without the ??\ prefix, while the Opus-created junction leaves the Print Name empty.

My guess is that some applications or Windows security/path validation code may fall back to the Substitute Name when the Print Name is missing, which exposes the ??\ prefix and may cause the path to be treated differently, resulting in the “untrusted mount point” error.

Could Opus fill in the Print Name for junctions, matching the behavior of mklink /J?

I find this API, there is "print name" in the structure, but junctions by Opus don't have this:

6

What is the "Reading Application" that has the problem with these junctions?

Is it a Microsoft Store app? Those seem to have issues that causes them to be unable to follow junctions in a lot of cases, with the error message you're seeing.

7

It is called "bookxnote", a win32 app made with c# or c++ and qt, not uwp

I don't know if it has always had this issue (and I just didn't notice before), or if it appeared after the Windows update these past couple of days.

8

I think the PrintName thing is a red herring and I doubt it would help. That just provides a "pretty" string to show to the user, it seems unlikely it would affect this error.

This blog post might explain what's going on:

It seems that in later versions of Windows junctions get flagged with the integrity level of the process that made them.

Presumably the application that's showing this error is setting its redirection trust policy to check the junction integrity level, and so won't follow junctions made by a lower integrity process.

9

We'll make it set the PrintName field in the next beta update after the 13.24 release (i.e. 13.24.1), but as I said above I doubt it will affect this issue.

10

thanks, I will test it again when it comes out