Most of the functions in the Windows file API first normalize a path into native NT form before making a system call such as
NtOpenFile(). Among other things, path normalization replaces forward slashes with backslashes. There are exceptions.
Of course, normalization is intentionally skipped for “\\?\” device paths. For example,
r"\\?\C:\Windows/System32" is an invalid path because NTFS reserves forward slash as an invalid name character. Like all code in the the native NT API and system services, the NTFS filesystem only handles backslash as a path separator.
>>> os.stat(r'\\?\C:\Windows/System32') Traceback (most recent call last): File "<stdin>", line 1, in <module> OSError: [WinError 123] The filename, directory name, or volume label syntax is incorrect: '\\\\?\\C:\\Windows/System32'
None of the
Path* API functions, such as
PathCchSkipRoot(), handle forward slash as a path separator.
When creating a relative symbolic link,
os.symlink()) does not replace forward slashes with backslashes in the target path. This creates a broken symlink since paths in the kernel only use backslash as a path separator.
>>> os.mkdir('spam') >>> open('spam\\eggs', 'w').close() >>> os.symlink('spam/eggs', 'eggslink') >>> os.stat('eggslink') Traceback (most recent call last): File "<stdin>", line 1, in <module> OSError: [WinError 123] The filename, directory name, or volume label syntax is incorrect: 'eggslink'
There are several other functions in the Windows API that take file paths and fail to normalize forward slashes as backslashes, such as
It’s really a laundry list of exceptions to the rule. Better to just use the native path separator than to worry about what does and does not support forward slashes.
Also, when paths are parsed as command-line arguments, applications may fail to handle paths that use forward slashes. Notably, the CMD shell has this problem. For example:
>>> os.system('dir C:/Windows') Parameter format not correct - "Windows".