4

Apparently, Windows (or at least some part of Windows) ignores multiple backslashes in a path and treats them as a single backslash. For example, executing any of these commands from a command prompt or the Run window opens Notepad:

C:\Windows\System32\Notepad.exe
C:\Windows\System32\\Notepad.exe
C:\Windows\System32\\\Notepad.exe
C:\Windows\System32\\\\Notepad.exe
C:\\Windows\\System32\\Notepad.exe
C:\\\Windows\\\System32\\\Notepad.exe

This can even work with arguments passed on the command line:

notepad "C:\Users\username\Desktop\\\\myfile.txt"

Is this behavior documented anywhere? I tried several searches, and only found this SO question that even mentions the behavior.

Note: I am not asking about UNC paths (\\servername), the \\?\ prefix, or the \\" double-quote escape.

Note: I stumbled upon this behavior while working with a batch file. One line in the batch file looked something like this:

"%SOME_PATH%\myapp.exe"

After variable expansion, the command looked like:

"C:\Program Files\Vendor\MyApp\\myapp.exe"

To my surprise, the batch file executed as desired and did not fail with some kind of "path not found" error.

Mogsdad
  • 44,709
  • 21
  • 151
  • 275
kevinbatchcom
  • 587
  • 5
  • 9
  • 5
    Microsoft, like most any software vendor, never documents their "it is wrong but I'll accept it anyway" workarounds. Documenting it legitimizes doing it wrong. – Hans Passant Oct 08 '15 at 22:37

2 Answers2

7

In most cases, Win32 API functions will accept a wide range of variations in the path name format, including converting a relative path into an absolute path based on the current directory or per-drive current directory, interpreting a single dot as "this directory" and two dots as "the parent directory", converting forward slashes into backslashes, and removing extraneous backslashes and trailing periods.

So something like

c:\documents\..\code.\\working\.\myprogram\\\runme.exe..

will wind up interpreted as

c:\code\working\myprogram\runme.exe

Some of this is documented, some is not. (As Hans points out, documenting this sort of workaround legitimizes doing it wrong.)

Note that this applies to the Win32 API, not necessarily to every application, or even every system component. In particular, the command interpreter has stricter rules when dealing with a long path, and Explorer will not accept the dot or double-dot and typically will not accept forward slashes. Also, the rules may be different for network drives if the server is not running Windows.

Harry Johnston
  • 35,639
  • 6
  • 68
  • 158
  • @Leon, thanks for the edit. In fact that entire paragraph was incorrect, I'd been misled by the behaviour of the the command interpreter. – Harry Johnston Feb 03 '17 at 21:37
-1

There is no consequence because you can't even name a file or folder with a backslash. So multiple consecutive backslashes will always be seen as one separator in the path.

kevinbatchcom
  • 587
  • 5
  • 9
Paul
  • 2,620
  • 2
  • 17
  • 27
  • This is not correct. You can `dir c:\ `, but you can not `dir c:\\ ` – MC ND Oct 09 '15 at 09:13
  • `dir C:\\ ` does not work, but `dir C:\Windows\\ ` does work. The `dir` command must use slightly different logic. – kevinbatchcom Oct 09 '15 at 15:40
  • 1
    Yes, many built-in commands parse pathnames themselves, and therefore have slightly different rules to the Win32 API. Presumably this is for backwards compatibility with DOS. If you say `dir c:\\Users\xyzzy` you get "The network path was not found" so it seems the double-backslash being so close to the start is confusing `cmd.exe` into thinking it is a UNC path. `notepad.exe` on the other hand is perfectly happy with the same syntax. – Harry Johnston Oct 09 '15 at 20:38
  • @MCND But in fact, the following code works `for %a in ("C:\\") do dir %~dpna` also `mkdir c:\\folder` too. `cd "c:\\"` Only `DIR` command is confused. It's the cons-example that proves the rule – Paul Oct 09 '15 at 21:06