# Compatibility issue with junctions

**URL:** <https://resource.dopus.com/t/compatibility-issue-with-junctions/59718>\
**Category:** Help & Support\
**Tags:** bug-report\
**Created:** [June 13, 2026, 7:24pm UTC](https://resource.dopus.com/t/compatibility-issue-with-junctions/59718 "2026-06-13T19:24:06Z")\
**Posts on this page:** 14\
**Page:** 1

<div class="post-metadata">

**Author:** ![ilcpm](https://resource.dopus.com/letter_avatar_proxy/v4/letter/i/8dc957/32.png) [@ilcpm](https://resource.dopus.com/u/ilcpm)\
**Post date:** [June 13, 2026, 7:24pm UTC](https://resource.dopus.com/t/compatibility-issue-with-junctions/59718/1 "2026-06-13T19:24:06Z")

</div>

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:

```plaintext
<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](https://resource.dopus.com/uploads/default/original/3X/3/4/349a0007e218ae1fa0091173d8065789c10abefb.png)

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

```plaintext
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:

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

```

then `dir /al` shows the target as:

```plaintext
<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:

```plaintext
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`?

---

<div class="post-metadata">

**Author:** ![Leo](https://resource.dopus.com/user_avatar/resource.dopus.com/leo/32/69732_2.png) [@Leo](https://resource.dopus.com/u/Leo)\
**Post date:** [June 13, 2026, 7:59pm UTC](https://resource.dopus.com/t/compatibility-issue-with-junctions/59718/2 "2026-06-13T19:59:10Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![ilcpm](https://resource.dopus.com/letter_avatar_proxy/v4/letter/i/8dc957/32.png) [@ilcpm](https://resource.dopus.com/u/ilcpm)\
**Post date:** [June 13, 2026, 8:22pm UTC](https://resource.dopus.com/t/compatibility-issue-with-junctions/59718/3 "2026-06-13T20:22:24Z")

</div>

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:

```plaintext
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:

```plaintext
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](https://resource.dopus.com/uploads/default/original/3X/0/5/054d513509958589872a30e6e2ed39ee706a26b8.png)

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](https://resource.dopus.com/uploads/default/original/3X/1/e/1e8b9e10f0893ad8978dee01a2b0da6f01501d11.png)

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

---

<div class="post-metadata">

**Author:** ![Leo](https://resource.dopus.com/user_avatar/resource.dopus.com/leo/32/69732_2.png) [@Leo](https://resource.dopus.com/u/Leo)\
**Post date:** [June 13, 2026, 8:46pm UTC](https://resource.dopus.com/t/compatibility-issue-with-junctions/59718/4 "2026-06-13T20:46:46Z")

</div>

> [@ilcpm](#):
>
> **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:

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).

---

<div class="post-metadata">

**Author:** ![ilcpm](https://resource.dopus.com/letter_avatar_proxy/v4/letter/i/8dc957/32.png) [@ilcpm](https://resource.dopus.com/u/ilcpm)\
**Post date:** [June 13, 2026, 8:56pm UTC](https://resource.dopus.com/t/compatibility-issue-with-junctions/59718/5 "2026-06-13T20:56:07Z")

</div>

See this picture:

 ![image](https://resource.dopus.com/uploads/default/original/3X/1/e/1e8b9e10f0893ad8978dee01a2b0da6f01501d11.png)

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:

> **[REPARSE\_DATA\_BUFFER (ntifs.h) - Windows drivers](https://learn.microsoft.com/en-us/windows-hardware/drivers/ddi/ntifs/ns-ntifs-_reparse_data_buffer)**
>
> The REPARSE\_DATA\_BUFFER structure contains reparse point data for a Microsoft reparse point.

---

<div class="post-metadata">

**Author:** ![Leo](https://resource.dopus.com/user_avatar/resource.dopus.com/leo/32/69732_2.png) [@Leo](https://resource.dopus.com/u/Leo)\
**Post date:** [June 13, 2026, 9:13pm UTC](https://resource.dopus.com/t/compatibility-issue-with-junctions/59718/6 "2026-06-13T21:13:05Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![ilcpm](https://resource.dopus.com/letter_avatar_proxy/v4/letter/i/8dc957/32.png) [@ilcpm](https://resource.dopus.com/u/ilcpm)\
**Post date:** [June 13, 2026, 9:22pm UTC](https://resource.dopus.com/t/compatibility-issue-with-junctions/59718/7 "2026-06-13T21:22:50Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![Jon](https://resource.dopus.com/user_avatar/resource.dopus.com/jon/32/12713_2.png) [@Jon](https://resource.dopus.com/u/Jon)\
**Post date:** [June 13, 2026, 11:51pm UTC](https://resource.dopus.com/t/compatibility-issue-with-junctions/59718/8 "2026-06-13T23:51:29Z")

</div>

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:

> **[Why Are My Junctions Not Followed? Exploring Windows Redirection Trust...](https://unit42.paloaltonetworks.com/junctions-windows-redirection-trust-mitigation/)**
>
> Junctions are a feature of the NT file system – and a common way that attackers exploit file system redirection attacks. Learn about mitigation.

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.

---

<div class="post-metadata">

**Author:** ![Jon](https://resource.dopus.com/user_avatar/resource.dopus.com/jon/32/12713_2.png) [@Jon](https://resource.dopus.com/u/Jon)\
**Post date:** [June 15, 2026, 4:31am UTC](https://resource.dopus.com/t/compatibility-issue-with-junctions/59718/9 "2026-06-15T04:31:01Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![ilcpm](https://resource.dopus.com/letter_avatar_proxy/v4/letter/i/8dc957/32.png) [@ilcpm](https://resource.dopus.com/u/ilcpm)\
**Post date:** [June 16, 2026, 5:22pm UTC](https://resource.dopus.com/t/compatibility-issue-with-junctions/59718/10 "2026-06-16T17:22:33Z")

</div>

thanks, I will test it again when it comes out

---

<div class="post-metadata">

**Author:** ![drventure](https://resource.dopus.com/letter_avatar_proxy/v4/letter/d/e274bd/32.png) [@drventure](https://resource.dopus.com/u/drventure)\
**Post date:** [August 28, 2026, 2:15pm UTC](https://resource.dopus.com/t/compatibility-issue-with-junctions/59718/11 "2026-08-28T14:15:32Z")

</div>

HI  
Just came across this exact same problem  
Everything was running with the previous version I had install. I literally just installed the latest vers (13.25 build 9524) and am now getting this error on all the junction points I have created. No other changes

Explorer and the command line work as normal. Only seems to effect Dopus.

Continued to test, I had to revert all the way back to the 13.24 version to get things working again, but everything DOES work properly in 13.24 build 9500

 ![image](https://resource.dopus.com/uploads/default/original/3X/e/d/edacb1c6a04709d7a16090c9269834518a3b8d07.png)

---

<div class="post-metadata">

**Author:** ![Leo](https://resource.dopus.com/user_avatar/resource.dopus.com/leo/32/69732_2.png) [@Leo](https://resource.dopus.com/u/Leo)\
**Post date:** [August 28, 2026, 2:45pm UTC](https://resource.dopus.com/t/compatibility-issue-with-junctions/59718/12 "2026-08-28T14:45:19Z")

</div>

You don't need to go back to 12.24. After installation, use File \> Exit Directory Opus, then start it again. Or reboot.

The issue is something the latest Inno Setup installers do when launching programs at the end of an installation. Re-launching the programs resolves the issue, and the next updates will have a workaround to prevent the issue.

---

<div class="post-metadata">

**Author:** ![drventure](https://resource.dopus.com/letter_avatar_proxy/v4/letter/d/e274bd/32.png) [@drventure](https://resource.dopus.com/u/drventure)\
**Post date:** [August 28, 2026, 2:59pm UTC](https://resource.dopus.com/t/compatibility-issue-with-junctions/59718/13 "2026-08-28T14:59:56Z")

</div>

Well, damn, didn't try completely terminating and restarting. That did the trick. Thanks!

---

<div class="post-metadata">

**Author:** ![unrealreality](https://resource.dopus.com/letter_avatar_proxy/v4/letter/u/35a633/32.png) [@unrealreality](https://resource.dopus.com/u/unrealreality)\
**Post date:** [September 1, 2026, 2:37pm UTC](https://resource.dopus.com/t/compatibility-issue-with-junctions/59718/14 "2026-09-01T14:37:42Z")

</div>

I just wanted to chime in that yes, I've had this same issue lately. And yea, Leo, restarting dopus fixes it (as it was fine in explorer but not opus). Version 13.25 here.

Good to know that there is a workaround in progress. Y'all rock!