[GH-ISSUE #127] [BUG] Long UNC Path (follow symlink) contains stray string #126

New issue

Closed

opened 2026-02-25 21:32:41 +03:00 by kerem · 4 comments

kerem commented

2026-02-25 21:32:41 +03:00

Owner

Originally created by @jackhab on GitHub (Aug 11, 2020).
Original GitHub issue: https://github.com/clechasseur/pathcopycopy/issues/127

Originally assigned to: @clechasseur on GitHub.

Describe the bug
The symlink path resolution works fine but the path contains stray string which makes the path unusable.

Symlinks pointing to network location contain "?\UNC".
Symlinks pointing to local drives contain "\\?".

For example:
Symlink to network: \\?\UNC\dc2012\system\mail
Symlink to local drive: \\?\C:\Users\User\OneDrive

To Reproduce
Enable Long UNC Path (follow symlink) in Settings.
Map a location via symbolic link in command line:
mklink /d LinkedPath c:\some\path
Explorer > right click LinkedPath > Path Copy > Examine the path

Expected behavior
\\dc2012\system\mail
C:\Users\User\OneDrive

Software
Path Copy Copy Version 19.0

Originally created by @jackhab on GitHub (Aug 11, 2020). Original GitHub issue: https://github.com/clechasseur/pathcopycopy/issues/127 Originally assigned to: @clechasseur on GitHub. **Describe the bug** The symlink path resolution works fine but the path contains stray string which makes the path unusable. Symlinks pointing to network location contain "?\UNC\". Symlinks pointing to local drives contain "\\\\?\". For example: Symlink to network: \\\\?\UNC\dc2012\system\mail Symlink to local drive: \\\\?\C:\Users\User\OneDrive **To Reproduce** Enable Long UNC Path (follow symlink) in Settings. Map a location via symbolic link in command line: mklink /d LinkedPath c:\some\path Explorer > right click LinkedPath > Path Copy > Examine the path **Expected behavior** \\\\dc2012\system\mail C:\Users\User\OneDrive **Software** Path Copy Copy Version 19.0

kerem

2026-02-25 21:32:41 +03:00

closed this issue
added the
bug
label

kerem commented

2026-02-25 21:32:42 +03:00

Author

Owner

@clechasseur commented on GitHub (Aug 11, 2020):

This is actually a valid path. See
https://docs.microsoft.com/en-us/dotnet/standard/io/file-path-formats#example-ways-to-refer-to-the-same-file

@clechasseur commented on GitHub (Aug 11, 2020): This is actually a valid path. See https://docs.microsoft.com/en-us/dotnet/standard/io/file-path-formats#example-ways-to-refer-to-the-same-file

kerem commented

2026-02-25 21:32:42 +03:00

Author

Owner

@jackhab commented on GitHub (Aug 11, 2020):

This is a valid path from Windows API point of view, but since this utility is used in Windows Explorer the ultimate validity test, IMHO, should be whether the path can pasted back to Explorer path drop-down or into File Open dialog box.

The only program which I've found to accept these paths is PowerShell.

@jackhab commented on GitHub (Aug 11, 2020): This is a valid path from Windows API point of view, but since this utility is used in Windows Explorer the ultimate validity test, IMHO, should be whether the path can pasted back to Explorer path drop-down or into File Open dialog box. The only program which I've found to accept these paths is PowerShell.

kerem commented

2026-02-25 21:32:42 +03:00

Author

Owner

@clechasseur commented on GitHub (Aug 11, 2020):

It's strange that it doesn't work - you're right, they need to be usable through Explorer. I'll look into it.

@clechasseur commented on GitHub (Aug 11, 2020): It's strange that it doesn't work - you're right, they need to be usable through Explorer. I'll look into it.

kerem commented

2026-02-25 21:32:42 +03:00

Author

Owner

@clechasseur commented on GitHub (Feb 13, 2021):

This bug is fixed. The next release should no longer copy non-working paths.

@clechasseur commented on GitHub (Feb 13, 2021): This bug is fixed. The next release should no longer copy non-working paths.