This is a low-resolution version of the logo of Windows XP by Microsoft, protected by copyright

Windows paths... what a mess

Notes published the
22 - 28 minutes to read, 5527 words
Categories: security, shell, windows
Keywords: WSL, antivirus, backup, cygwin, mount, powershell, security, shell, windows

I wanted to ensure that some scripts of mine were robust enough to work even with the strangest path.

I set up different folders to ensure the correctness of my programs, just to realize how inconsistent the integrated tools of the operating system are at dealing with paths.

cmd, powershell, explorer, …​ they all follow different rules.

Test matrix

These are the paths I’ve created on my drive.

    # root drive
    D:\
\\?\D:\
    # folder with spaces
    D:\a b
\\?\D:\a b
    # folder with '
    D:\a b\a'b
\\?\D:\a b\a'b
    # folder with parenthesis
    D:\a b\a'b\a(b)
\\?\D:\a b\a'b\a(b)
    # folder with non-ASCII characters
    D:\a b\a'b\a(b)\äb
\\?\D:\a b\a'b\a(b)\äb
    # folder with non-ASCII characters
    D:\a b\a'b\a(b)\äb\àb
\\?\D:\a b\a'b\a(b)\äb\àb
    # folder with `
    D:\a b\a'b\a(b)\äb\àb\a`b
\\?\D:\a b\a'b\a(b)\äb\àb\a`b
    # folder with emoji
    D:\a b\a'b\a(b)\äb\àb\a`b\💋
\\?\D:\a b\a'b\a(b)\äb\àb\a`b\💋
    # folder with an invalid character
    D:\a b\a'b\a(b)\äb\àb\a`b\💋\a"b
\\?\D:\a b\a'b\a(b)\äb\àb\a`b\💋\a"b
    # folder with ; at the end
    D:\a b\a'b\a(b)\äb\àb\a`b\💋\a"b\ab;
\\?\D:\a b\a'b\a(b)\äb\àb\a`b\💋\a"b\ab;
    # folder named ~
    D:\a b\a'b\a(b)\äb\àb\a`b\💋\a"b\ab;\~
\\?\D:\a b\a'b\a(b)\äb\àb\a`b\💋\a"b\ab;\~
    # folder usable only with UNC
    D:\a b\a'b\a(b)\äb\àb\a`b\💋\a"b\ab;\~\ab.
\\?\D:\a b\a'b\a(b)\äb\àb\a`b\💋\a"b\ab;\~\ab.
    # folder with trailing space
    D:\a b\a'b\a(b)\äb\àb\a`b\💋\a"b\ab;\~\ab \ab
\\?\D:\a b\a'b\a(b)\äb\àb\a`b\💋\a"b\ab;\~\ab \ab
    # path longer than 260 characters
    D:\11223344556677889900\11223344556677889900\11223344556677889900\....
\\?\D:\11223344556677889900\11223344556677889900\11223344556677889900\....
    # network drive
      \\server\path
\\?\UNC\server\path
    # wsl
      \\wsl.localhost\Debian\tmp\
\\?\UNC\wsl.localhost\Debian\tmp\
      \\wsl.localhost\Debian\tmp\"
\\?\UNC\wsl.localhost\Debian\tmp\"
      \\wsl$\Debian
\\?\UNC\wsl$\Debian
      \\wsl$\Debian\tmp
\\?\UNC\wsl$\Debian\tmp
      \\wsl$\Debian\tmp\"
\\?\UNC\wsl$\Debian\tmp\"

For generating the local paths, I’ve used Cygwin:

mkdir -p /cygdrive/d/a\ b/a\'b/a\(b\)/äb/àb/a\`b/💋/a\"b/ab\;\~/ab.
mkdir -p /cygdrive/d/a\ b/a\'b/a\(b\)/äb/àb/a\`b/💋/a\"b/ab\;\~/ab\ /ab
mkdir -p /cygdrive/d/11223344556677889900/11223344556677889900/11223344556677889900/11223344556677889900/11223344556677889900/11223344556677889900/11223344556677889900/11223344556677889900/11223344556677889900/11223344556677889900/11223344556677889900/11223344556677889900/11223344556677889900/11223344556677889900/
Warning ⚠️
 I tested those paths in two similar environments. I wouldn’t be surprised if differently configured Windows versions would behave differently.

Windows does not support PATHs with ", did I really test them?

Double quotes are reserved 🗄️, it is not possible to create a valid path with it on a Windows system, even with cygwin.

As described in the section "Forbidden characters in filenames" 🗄️, cygwin remaps " to another (unused) Unicode character.

Still, I’ll write the remapped character as ", which is much more readable than (rendering might vary, the actual hex value is ef80a2).

There are not many characters that are reserved, testing for " did not cost too much time, as I’ve yet not found a Windows tool that had issues with it, and it ensured that my quoting in Cygwin scripts is better than average.

But I also tested paths with a real " character, as there are environments where " is not reserved and where Windows has access too. For example, it is trivial to create a folder named " in WSL.

Note 📝
 In case of a real ", wslpath translates is to ef80a2 too.

It seems there is no way to cd in a folder with a real " with powershell or cmd.

During my test I extensively used powershell, cmd, bash, and far 🗄️.

far is a file manager for Windows (later ported to Linux system too), and is the only Windows tool I am aware of (excluding tools based on Cygwin) that worked without inconsistencies on nearly all tested paths.

Instead of writing the hard-to-read character, use wslpath or cygpath to convert " to the correct symbol, or use a file manager to navigate interactively to the correct folder.

What are the paths prefixed with \\ ?

Some Windows programs impose certain limits on possible filenames.

For example, explorer.exe makes it difficult to create a filename that begins with a dot (.), but it is not problematic to access or rename those.

Some programs cannot handle paths that are longer than TMP_MAX characters (approximately 260 characters). For this reason, some programs try to avoid creating such long paths.

Another limitation is that paths with leading dots or whitespaces are not supported by the shell:

Do not end a file or directory name with a space or a period. Although the underlying file system may support such names, the Windows shell and user interface do not.

— File Naming Conventions 🗄️
Note 📝
 In this context, the Windows shell is, in practice explorer.exe and all its dialogs.

All paths beginning with \\ are UNC paths, and UNC stands for "Universal Naming Convention" or "Uniform Naming Convention".

Without UNC you will not be able, with explorer.exe, cmd, or PowerShell to create a folder named test.

If a path begins with \\?\ then some validations are skipped, and the path is sent more or less as is to the filesystem.

This article on googleprojectzero of 2016 🗄️ provides a more in-depth exploration, and calls paths beginning with \\?\ "Root Local Device path".

Note 📝
 the article also presents "Local Device paths", which start with \\.\. I was not aware of those, but I’m too lazy now to compare how local device paths are handled in the different environments. I was also not aware of the difference between UNC and "Root Local Device paths" until now.

Programs using Root Local Device paths can, for example, access long paths without restriction, and create paths with leading dots and spaces.⁠[1]

UNC is otherwise used to access network locations that are not mapped to a drive letter.⁠[2]

explorer.exe partially supports Root Local Device paths

Even if a program can access \\?\C:\test. and its files and subfolders, explorer.exe will claim that the folder and its content do not exist, even if it will list the folder.

As a side effect, all applications that use the explorer.exe dialog for opening or saving files, will not be able to open files residing there from the GUI.

If a folder is accessible without a UNC path, like \\?\C:\test, then explorer.exe will access it too. You can type \\?\C:\test in the address bar and explorer.exe will convert it to C:\test.

For network locations, there seem to be some inconsistencies. Typing \\?\UNC\wsl.localhost\Debian\tmp in the address bar does not work, but explorer.exe \\?\UNC\wsl.localhost\Debian\tmp opens the correct location, and the address bar displays \\wsl.localhost\Debian\tmp

\\wsl.localhost\Debian\tmp works correctly as a parameter for explorer.exe and as input in the address bar.

Accessing the root folder as Root Local Device form is unnecessarily hard

From PowerShell

cd     C:\         # success
cd \\?\C:\         # failure
cd     C:\windows  # success
cd \\?\C:\windows  # success

At least there is a workaround: cd -literal \\?\C:\.

But if you want to access the parent folder, then the parameter -literal does not work because when using Root local Devices, cd seems to be searching a folder named ...

cd C:\windows\system32     # success, cwd is C:\windows\system32
cd ..                      # success, cwd is C:\windows
cd ..                      # success, cwd is C:\
cd ..                      # success, cwd is C:\
cd ..                      # success, cwd is C:\
cd -literal ..             # success, cwd is C:\

cd \\?\C:\windows\system32 # success, cwd is \\?\C:\windows\system32
cd ..                      # success, cwd is \\?\C:\windows
cd ..                      # failure, cwd is \\?\C:\windows
cd -literal ..             # failure, cwd is \\?\C:\windows

Other cmdlets suffer a similar limitation:

dir     C:\       # success
dir \\?\C:\       # failure
dir     C:\Users  # success
dir \\?\C:\Users  # success

dir supports the parameter -literal too, thus it can be used as a workaround too.

At first, I thought that, counterintuitively, \\?\C:\ is not a valid UNC path. Then, after realizing that with -literal it is possible to access that folder, I assumed that cd and other cmdlets are buggy. My assumption would have been that they strip the leading \, which is OK for every folder except the root folder, as \\?\C: is not a valid UNC path.

After those considerations, I’ve noticed that some functions of the Win32 API seem to have the same limitation:

Note Prepending the string "\\?\" does not allow access to the root directory.

— API of 🗄️ FindFirstFile 🗄️

I currently do not know what to think.

Is \\?\C:\ a valid UNC path? If not, why not? It does not really seem to make sense. If it is not valid, why can it be accessed if you try hard enough?

If it is valid, why is it so hard to access it with Powershell?⁠[3], and why do some fundamental Windows functions, like FindFirstFile, do not support it?

Note 📝
 Both \\?\C:\ and \\?\C: in the address bar of explorer.exe open the correct location, and are converted to C:\.

Similar consideration holds for the Root Local Device paths for network drives; the root folder is not handled consistently.

In this test scenario, \\wsl.localhost\Debian\ points to the root folder of a Debian WSL environment, and cd \\wsl.localhost\Debian\ works without issues, but using a path prefixed with \\?\ provides an inconsistent experience, similar to \\?\C:\:

cd                \\wsl.localhost\             # failure
cd          \\?\UNC\wsl.localhost\             # failure
cd -literal \\?\UNC\wsl.localhost\             # failure
cd                \\wsl.localhost\Debian\      # success
cd          \\?\UNC\wsl.localhost\Debian\      # failure
cd -literal \\?\UNC\wsl.localhost\Debian\      # success
cd          \\?\UNC\wsl.localhost\Debian       # failure
cd -literal \\?\UNC\wsl.localhost\Debian       # success, while "cd -literal \\?\C:" fails
cd          \\?\UNC\wsl.localhost\Debian\tmp   # success
cd -literal \\?\UNC\wsl.localhost\Debian\tmp   # success
Note 📝
 \\?\UNC\wsl.localhost and \\wsl.localhost both work in explorer.exe, as parameters and are typed in the address bar.

.. and . do not work as expected

.. and . cannot be part of a UNC path, and will work differently in PowerShell if the current working directory is a UNC path:

cd          \\?\C:\windows\system32                   # success
cd          \\?\C:\windows\system32\..                # double failure(!)
cd -literal \\?\C:\windows\system32\..                # failure
cd          \\?\C:\windows\system32\; cd ..           # success
cd          \\?\C:\windows\system32\; cd -literal ..  # failure
cd              C:\windows\system32\; cd -literal ..  # success
cd          \\?\C:\windows\.                          # failure
cd -literal \\?\C:\windows\.                          # failure
cd          \\?\C:\windows\;          cd .            # success
cd          \\?\C:\windows\;          cd -literal .   # failure
cd              C:\windows\;          cd -literal .   # success

I guess this behavior is also implied in the documentation:

Because it turns off automatic expansion of the path string, the "\\?\" prefix also allows the use of ".." and "." in the path names, which can be useful if you are attempting to perform operations on a file with these otherwise reserved relative path specifiers as part of the fully qualified path.

— Usage of .. and . 🗄️

Honestly, it is not clear to me why . and .. cannot be used like they can be used without Root Local Device paths, and what use cases it should enable.

Note 📝
 \\?\C:\windows\system32\.. does not cause an error in explorer.exe and opens C:\windows.

The current working directory is not a Root Local Device path in PowerShell

> cd \\?\C:\Users
> echo $PWD.Path
Microsoft.PowerShell.Core\FileSystem::\\?\C:\Users

At least it can be used as a path in some PowerShell commands, for example cd $PWD.Path also works in this case, but most programs will not be able to do something with a path beginning with Microsoft.PowerShell.Core\FileSystem.

Why not have \\?\C:\Users or C:\Users as $PWD.Path?

To query the path, you can use Convert-Path .:

> cd \\?\C:\Users
> echo $PWD.Path
Microsoft.PowerShell.Core\FileSystem::\\?\C:\Users
> Convert-Path .
\\?\C:\Users
> Convert-Path $PWD.Path
\\?\C:\Users
Note 📝
 Convert-Path accepts the -literal parameter too, otherwise it would also not work with \\?\C:\. Note that Convert-Path . works even if the current working directory is \\?\C:\.

File listing is inconsistent

# without Root Local Device path; list files in the folder
> dir C:\Users\
    Directory: C:\Users

Mode                 LastWriteTime         Length Name
d-----        04.11.2024     11:27                Administrator
d-r---        29.06.2024     13:56                Public

# with Root Local Device path; shows only directory name
> dir \\?\C:\Users\
    Directory: \\?\C:

Mode                 LastWriteTime         Length Name
d-r---        29.06.2024     13:56                Users

# with Root Local Device path and -literal; list files in the folder
> dir -literal \\?\C:\Users\
    Directory: \\?\C:\Users

Mode                 LastWriteTime         Length Name
d-----        09.12.2024     13:09                Administrator
d-r---        29.06.2024     13:56                Public

# with . as Root Local Device path; list files in the folder
> cd \\?\C:\Users
> dir .
    Directory: \\?\C:\Users

Mode                 LastWriteTime         Length Name
d-----        09.12.2024     13:09                Administrator
d-r---        29.06.2024     13:56                Public
...

# with the parent of Root Local Device path; outputs the user directory
# this seems to happen only when .. points to a drive, like \\?\C:\
> cd \\?\C:\Users
> dir ..\

    Directory: C:\Users\Administrator
...


# with the parent of Root Local Device path; list files in the folder
> cd \\?\C:\Users\Public
> dir ..\
    Directory: \\?\C:\Users

Mode                 LastWriteTime         Length Name
d-----        09.12.2024     13:09                Administrator
d-r---        29.06.2024     13:56                Public


# with grandparent of Root Local Device path; error
# this seems to happen only when .. points to a drive, like \\?\C:\
> dir ..\..
Get-ChildItem : Cannot find path '' because it does not exist.

I’m still not sure which is the best way to list the content of a folder.

You cannot start cmd in any UNC path

# from powershell
> cd \\?\C:\Users
> cmd

CMD.EXE was started with the above path as the current directory.
UNC paths are not supported.  Defaulting to Windows directory.


# cwd is C:\Windows

There is a setting that should work since Windows XP 🗄️; to configure cmd to "support" UNC paths, which also adds support for Root Local Device paths.

This can be done by applying the following change to the registry:

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Command Processor]
"DisableUNCCheck"=dword:00000001

Now it is possible to start cmd from a UNC path.

In cmd you apparently cannot cd from a UNC path

After you’ve started successfully cmd in a UNC path, you will notice that you cannot cd anywhere else:

# from powershell
> cd \\?\C:\Users
> cmd
# cwd is \\?\C:\Users
> dir
 Volume in drive \\?\C: has no label.
 Volume Serial Number is AC76-E3D2

 Directory of \\?\C:\Users

29.06.2024  12:56    <DIR>          .
04.11.2024  11:27    <DIR>          Administrator
29.06.2024  12:56    <DIR>          Public
               0 File(s)              0 bytes
               3 Dir(s)  32.032.665.600 bytes free

> cd Public
The system cannot find the path specified.
# cwd is still \\?\C:\Users
> cd C:\
# cwd is still \\?\C:\Users

After experimenting a little bit more I found a way out: you need to change the drive! If your machine does not have a second drive, it’s not a problem, changing to the current drive is enough. A side effect of this approach is that you must use an absolute path, even if you want to access a subfolder:

> cd \\?\C:\Users
> cmd
# cwd is \\?\C:\Users
> C:
# cwd is the home directory of the current user
> cd C:\Users\Public
# cwd is C:\Users\Public
> exit
# in powershell, cwd is \\?\C:\Users

> cmd
# cwd is \\?\C:\Users
> cd /d C:\Users\Public
# cwd is C:\Users\Public

In cmd you cannot cd to an UNC path

Even if you can start successfully cmd in a UNC path, you will notice that you still cannot cd in a directory:

> cd \\?\C:\Users
'\\?\C:\Users'
CMD does not support UNC paths as current directories.

I found no workaround for this limitation.

If you must use a Root Local Device path to bypass some limitations, programs will not be started in the current directory

As far as I could observe if the current working directory is inside test. (could be a subfolder), then all programs invoked from PowerShell

  • will be started in a separate Windows

  • will be started in the C:\Windows folder

If there is a folder with the same name minus the leading dot, then PowerShell will be executed there.

As example:

> mkdir \\?\C:\Users\username\test1
> cd    \\?\C:\Users\username\test1
> powershell
# starts powershell in \\?\C:\Users\username\test1
# parent shell waits until child shell ends

> mkdir \\?\C:\Users\username\test2.
> cd    \\?\C:\Users\username\test2.
> powershell
# starts powershell in C:\Windows in a separate window
# parent shell does not wait until child shell ends

> mkdir \\?\C:\Users\username\test2  # without trailing dot
> mkdir \\?\C:\Users\username\test2.
> cd    \\?\C:\Users\username\test2.
> powershell
# starts powershell in \\?\C:\Users\username\test2, without trailing dot
# parent shell waits until child shell ends
Note 📝
 explorer.exe behaves similarly. It will open the wrong directory (and even show the wrong folder name in the address bar) instead of giving an error if a folder with the same name minus the leading dots exists.

This also means that you cannot replace some builtins with programs that you might consider superior, or simply prefer to use to have a more uniform experience with other platforms.

Subshells (like & { echo a }) are executed in the current directory and console.

This behavior also affects graphical applications when using relative paths:

> mkdir \\?\C:\Users\username\test.
> cd \\?\C:\Users\username\test.
> echo a > file.txt
> notepad++ .\file.txt # error, file.txt not found
> notepad++ \\?\C:\Users\username\test.\file.txt # opens file.txt

In the first case, notepad++ is unable to find the file because it is executed from C:\Windows, and there is no file.txt in C:\Windows, although it seems that the user executed the program from the right directory.

This inconsistent behavior makes working with Root Local Device path, when those are required, problematic.

I see little reason for those restrictions and can hardly imagine a Windows program having issues with a current working directory ending with a dot, and preferring to be executed from the wrong location. If it has to interact with relative files or the current directory, it should better be the right one.

Short mentions on paths longer than MAX_PATH

I found out the hard way that it is not possible to start Windows processes if the current path is longer than MAX_PATH.

This behaviour is documented in SetCurrentDirectory, and still holds in Windows 11:

Setting a current directory longer than MAX_PATH causes CreateProcessW to fail.

— SetCurrentDirectory on CreateProcess 🗄️

This is another situation where using, from PowerShell, a cmdlet instead of an external program can be useful. For example Get-Content does not fail if invoked from a directory with a long path, while programs like bat.exe or less.exe do not even start.

As long as you use a cygwin shell and cygwin tools, this limitation does not seem to exist; starting a non-cygwinprogram from a cygwin shell will fail.

A limited workaround is to create a subdirectory where normally processes are started in a different directory, although I’m not confident that this behaviour is documented as such and thus garanteed to work consistently

> cd $PATH_LONGER_THAN_PATH_MAX
# NOTE: CWD is automatically a Root Local Device paths
> powershell                       # failure
> mkdir a.                         # success
> cd a.                            # success
> powershell                       # start powershell in C:\Windows in a separate window

Conclusion on UNC paths

I can see why it is desirable to have explorer.exe failing to create problematic files and directories, this way users cannot accidentally create them.

However, I fail to see why it must be so difficult to interact with existing files and directory structures, especially after opting in by using a dedicated syntax.

Avoid Root Local Device paths if you can

There are simply too many drawbacks and inconsistencies.

Enable DisableUNCCheck

It does not hurt and helps when working with unmounted network drives.

If cmd is executed in the "wrong" directory, who knows what are the possible side effects. Thus it is better to reduce the amount of situations where this can happen.

Tools for dealing with problematic paths

While you should avoid creating problematic paths on Windows, such paths might be located on a network drive or might have been created by a rouge program.

TL;DR: It can happen that you have to interact with them.

You can mount folders, this bypasses most issues unless you want to delete or rename the folder, and it might not be that practical if you need to traverse multiple directories.

Fortunately, there exists programs that work out of the box with all those paths.

Cygwin shell and its packaged tools

This might sound like a rant, but I do not care if Cygwin (or git-bash, WSL, …​) and its shells are not labeled as first-class citizens, and if PowerShell is considered superior because it has some type-safety.

What matters is that those shells have none of the listed inconsistencies, they can access all paths.

Long paths, paths ending with trailing dots or space, paths containing a ", …​, you do not even need to use a different syntax to access any of those folders.

Every program packaged for those environments works as intended; not because they are carefully crafted, they work because the file system abstraction is simpler and more difficult to mess up, at least to a certain extent. Programs based on script might fail to quote the path correctly, especially since both ' and " are valid path characters, but it is, for example, not that hard to traverse all folders through a GUI or TUI. The Windows environment also has to deal with ', and when interacting with an external system, " becomes valid too.

Cygwin even improves the situation with `cmd`a little bit.

This snippet of code works even when DisableUNCCheck is not enabled;

  • you can start cmd in a path where UNC is otherwise required

  • you can cd out of a path where UNC is otherwise required without /d

Nonetheless, not everything will work correctly:

#from cygwin
> mkdir test.
> cd test.
> cmd
#cwd is C:\...\test.
> mkdir a # success, creates subdirectory a
> dir     # failure
> cd ..   # success

With PowerShell, the situation is worse, as it behaves differently depending if it is invoked from the Cygwin shell directly or cmd, and in both cases, it does not do the desired thing:

# from cygwin
> mkdir test.
> cd test.
> cmd
# current shell is cmd
# cwd is C:\...\test.
> powershell
The current directory is invalid.
# current shell is still cmd(!)
> exit
# cygwin shell
> powershell
# current shell is powershell
# cwd is C:\Windows\System32\WindowsPowershell\v1.0

Use far as additional file manager

It is the only non-cygwin-based program that was able to navigate all the folders I tested. Not only that but far was also able to

  • create all folders I’ve tested

  • rename those folders to something else

  • copy the content in and out

  • open external programs and provide the correct path to the called application (unless the current working directory was longer than MAX_PATH)

One would normally take those features for granted, but considering that most Windows-integrated components will fail at one task or another, it is a big plus.

Other programs?

I did not find other programs able to handle paths consistently. Granted, I do not know a lot of alternate file managers and shells for Windows, so I am confident that there are other tools that went the extra mile to support UNC paths as consistently as possible.

For developers

If you are developing a Windows application, try to avoid validating paths too much. Most programs that validated them manually did fail to parse UNC paths, without even considering Root Local Device paths.

On top of that, there are also dos paths, which might or might not be enabled at a system level.

For most programs there is little to do; the limitations are those of the shell (both graphical and command line); if the program is started in the wrong directory, there is nothing a program can do.

There are at least four types of programs that IMHO should go the extra mile and take care to work correctly with UNC and Root Local Device paths, eventually even use them internally to provide a more uniform experience to the end user.

The first category is command-line environments. cygwin is doing the right thing. If you are implementing your own shell, be sure that as many programs as possible are started in the correct directory, and that you can navigate all possible paths.

The second category is file managers. There should be no need to prefix a path with \\?\, the file manager should take care of it internally. If a program is executed for opening a file, the program should be executed with an absolute path to the file, or from the correct location and a relative path.

With far it is possible, for example, to navigate without issues in directories with leading dots, and open and edit files with the configured editor, as long as the editor accepts the provided path as a parameter.

The third category is security programs. The last thing you want is for malware to put itself in a location that your antivirus cannot reach. Thus an antivirus should be able to navigate and open all files in all locations, no matter how they are named.

The fourth category is backup programs. Everything that is contained in a folder should be archived correctly, there is little excuse to skip files and folders that have an uncommon name. If you cannot access them, be sure to state it loud and clearly when performing a backup.

In those cases, one should test explicitely how the Windows API works with and without UNC paths, I guess it will not match the behavior of PowerShell and explorer.exe depending on the function.

Otherwise, until Windows provides a consistent way to deal with UNC paths, there is little reason to try to support them for most programs. The easiest workaround is to move the content somewhere else, and then back, or to use a mount point.

Maybe at some point, there will be a registry settings 🗄️ enabling support for all file names without using UNC paths, just like Windows 10 introduced HKLM\SYSTEM\CurrentControlSet\Control\FileSystem\LongPathsEnabled for enabling long paths by default in Windows 10.

Addendum: starting external programs on Windows Terminal

If you use Windows Terminal (available by default since Windows 11), then you can use it to start a shell in a specific location 🗄️.

The parameter -d accepts paths in UNC forms too, Root Local Device paths included, but it also has issues with root locations and where a UNC path is required. I noticed different behaviors on different machines (Windows 11 vs Windows Server 2025) but did not investigate further what the root cause would be.

wt.exe -d \\?\C:\                        # starts powershell with empty $PWD, cwd is C:\ on Windows 11, cwd is user home on Windows Server 2025
wt.exe -d \\?\D:\                        # starts powershell with empty $PWD, cwd is C:\ on Windows 11, cwd is user home on Windows Server 2025
wt.exe -d \\?\F:\                        # starts wt with error message that \\?\F:\a is not a valid directory, F:/ does not exist
wt.exe -d \\?\C:\Users                   # starts powershell in \\?\C:\Users
cd -literal \\?\C:\; wt.exe -d .         # starts wt with an error message that \\?\C:\. is not a valid directory
cd \\?\C:\Users; wt.exe -d .             # starts powershell in \\?\C:\Users
cd \\?\C:\Users; wt.exe -d ..            # starts wt with error message that \\?\C:\Users\.. is not a valid directory
cd \\?\C:\Users\Public; wt.exe -d ..     # starts powershell in \\?\C:\Users
cd \\?\C:\test.;wt.exe -d \\?\C:\test.   # starts wt with error message that \\?\C:\test. is not a valid directory

wt.exe -d \\?\UNC\wsl.localhost\Debian                 # starts powershell with empty $PWD, cwd is C:\ on Windows 11, cwd is user home on Windows Server 2025
wt.exe -d \\?\UNC\wsl.localhost\Debian\                # starts powershell with empty $PWD, cwd is C:\ on Windows 11, cwd is user home on Windows Server 2025
wt.exe -d \\?\UNC\wsl.localhost\Debian\home            # starts powershell in \\?\UNC\wsl.localhost\Debian\home
cd \\?\UNC\wsl.localhost\Debian\home; wt.exe -d .      # starts powershell in \\?\UNC\wsl.localhost\Debian\home
cd \\?\UNC\wsl.localhost\Debian\home; wt.exe -d ..     # starts powershell with empty $PWD, cwd is C:\ on Windows 11, cwd is user home on Windows Server 2025
cd \\?\UNC\wsl.localhost\Debian\tmp\test; wt.exe -d .. # starts powershell in \\?\UNC\wsl.localhost\Debian\tmp
cd \\?\UNC\wsl.localhost\Debian\tmp\test.; wt.exe -d . # wt.exe failed to run(!)
wt.exe -d . \\?\UNC\wsl.localhost\Debian\tmp\test.;    # starts wt with error message that \\?\UNC\wsl.localhost\Debian\tmp\test. is not a valid directory
wt.exe -d . \\wsl.localhost\Debian\tmp\test.;          # starts wt with error message that \\wsl.localhost\Debian\tmp\test. is not a valid directory
Note 📝
 the difference in behavior between Windows 11 and Windows Server 2025 might be caused that in Windows Server 2025 I was using the administrator account.

Bonus test: path with trailing space

I expected the behavior to be the same as a folder with a leading dot, but was I wrong.

For whatever reason, I decided to test it once and…​ again, inconsistencies. Thus I’ve added a folder with a leading space to the test suite.

> mkdir '\\?\C:\Users\<username>\test '         # success
> cd    '\\?\C:\Users\<username>\test '         # failure(!)
> cd        'C:\Users\<username>\test '         # failure
> mkdir '\\?\C:\Users\<username>\test \test'    # success
> cd    '\\?\C:\Users\<username>\test \test'    # success
> cd ..                                         # failure
> cd        'C:\Users\<username>\test \test'    # success(!)
> cd ..                                         # failure
> cmd
> cd    "C:\Users\<username>\test "             # failure
> cd    "C:\Users\<username>\test \test"        # success
> cd ..                                         # failure
> dir   "C:\Users\<username>\test "             # failure
> mkdir "C:\Users\<username>\test \a"           # success
> explorer ..                                   # failure, opens document folder of current user
> explorer .                                    # success
> explorer "C:\Users\<username>\test "          # failure, opens document folder of current user
# typing "C:\Users\<username>\test \" without quotes in the address bar of explorer.exe changes location to the correct folder, but fails without trailing backslash

# open a cygwin shell
> cd "/cygdrive/c/Users/<username>/test "       # success
> cmd                                           # success, cwd is "C:\Users\<username>\test "
> dir                                           # failure
> mkdir test2                                   # success
> exit
> powershell                                    # starts powershell in C:\Windows\System32\WindowsPowerShell\v1.0

The TL;DR is that paths with trailing spaces seem to be harder to cd compared to paths with a trailing dot. On the other hand, subfolders are supported both by cmd and PowerShell, thus it can be accessed and navigated "easily" without even using UNC paths, while folders with a trailing dot "poison" the whole subfolder hierarchy.

explorer.exe does not support folders with trailing dots, but partially supports folders with trailing spaces:

  • it can navigate such paths

  • does not support them as command-line parameters, unless providing a subfolder

  • is unable to delete and rename them

  • can only create a subfolder, not files, in the subfolder it is possible again to create files

And I’m happy to report that both Cygwin and far have no issues with paths with leading spaces, even if there are a lot of good reasons for avoiding them.

1. Since Windows 10 the restrictions about long paths have been softened, there should be little reason to resort to UNC paths just for accessing paths that exceed 260 characters.
2. A folder, and also a network location, can be mounted as described here
3. My assumption is that PowerShell always strips the trailing \

Do you want to share your opinion? Or is there an error, some parts that are not clear enough?

You can contact me anytime.