Legacy DOS device path resolution information incorrect on Windows 11 machine #41193
Assignees
Labels
doc-bug
Problem with the content; needs to be fixed [org][type][category]
dotnet-fundamentals/svc
in-pr
This issue will be closed (fixed) by an active pull request.
okr-health
okr-quality
Content-quality KR: Concerns article defects (bugs), freshness, or build warnings.
Pri1
High priority, do before Pri2 and Pri3
📌 seQUESTered
Identifies that an issue has been imported into Quest.
Comments
issues-automation
bot
added
dotnet-fundamentals/svc
Pri1
adegeo
added
the
doc-bug
dotnet-policy-service
bot
added
the
okr-quality
|
Thank you for reporting this. I verified that this is a change in Win11 as Win10 operates as documented. |
sequestor
bot
added
📌 seQUESTered
dotnet-policy-service
bot
added
the
in-pr
EliahKagan
added a commit
to EliahKagan/gitoxide
that referenced
this issue
Aug 30, 2024
When invoking `git` to find the configuration file path associated with the `git` installation itself, this sets `GIT_DIR` to a path that cannot be a `.git` directory for any repository, to keep `git config -l` from including any local scope entries in the output of the `git config -l ...` command that is used to find the origin for the first Git configuration variable. Specifically, a path to the null device is used. This is `/dev/null` on Unix and `NUL` on Windows. This is not a directory, and when treated as a file it is always treated as empty: reading from it, if successful, reaches end-of-file immediately. This problem is unlikely since GitoxideLabs#1523, which caused this `git` invocation to use a `/tmp`-like location (varying by system and environment) as its current working directory. Although the goal of that change was just to improve performance, it pretty much fixed the bug where local-scope configuration could be treated as installation-level configuration when no configuration variables are available from higher scopes. This change further hardens against two edge cases: - If the `git` command is an old and unpatched vulnerable version in which `safe.directory` is not yet implemented, or in which GHSA-j342-m5hw-rr3v or other vulnerabilities where `git` would perform operations on untrusted local repositories owned by other users are unpatched, then a `.git` subdirectory of a shared `/tmp` or `/tmp`-like directory could be created by another account, and its local configuration would still have been used. (This is not a bug in gitoxide per se; having vulnerable software installed that other software may use is inherently insecure. But it is nice to offer a small amount of protection against this when readily feasible.) - If the `/tmp`-like location is a Git repository owned by the current user, then its local configuration would have been used. Any path guaranteed to point to a nonexistent entry or one that is guaranteed to be (or to be treated as) an empty file or directory should be sufficient here. Using the null device, even though it is not directory-like, seems like a reasonably intuitive way to do it. A note for Windows: There is more than one reasonable path to the null device. One is DOS-style relative path `NUL`, as used here. One of the others, which `NUL` in effect resolves to when opened, is the fully qualified Windows device namespace path `\\.\NUL`. I used the former here to ensure we avoid any situation where `git` would misinterpret a `\` in `\\.\NUL` in a POSIX-like fashion. This seems unlikely, and it could be looked into further if reasons surface to prefer `\\.\NUL`. One possible reason to prefer `\\.\NUL` is that which names are treated as reserved legacy DOS device names changes from version to version of Windows, with Windows 11 treating some of them as ordinary filenames. However, while this affects names such as `CON`, it does not affect `NUL`, at least written unsuffixed. I'm not sure if any Microsoft documentation has yet been updated to explain this in detail, but see: - dotnet/docs#41193 - python/cpython#95486 (comment) - python/cpython#95486 (comment) At least historically, it has been possible on Windows, though rare, for the null device to be absent. This was the case on Windows Fundamentals for Legacy PCs (WinFPE). Even if that somehow were ever to happen today, this usage should be okay, because attempting to open the device would still fail rather than open some other file (as may even be happening in Git for Windows already), the name `NUL` would still presumably be reserved (much as the names `COM?` where `?` is replaced with a Unicode superscript 1, 2, or 3 are reserved even though those devices don't really exist), and I think `git config -l` commands should still shrug off the error opening the file and give non-local-scope configuration, as it does when `GIT_DIR` is set to a nonexistent location.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Type of issue
Outdated article
Description
The following information about how legacy DOS device paths are parsed is inaccurate on the Windows 11 machine I tested it on.
#A path that begins with a legacy device name is always interpreted as a legacy device by the Path.GetFullPath(String) method. For example, the DOS device path for CON.TXT is \.\CON, and the DOS device path for COM1.TXT\file1.txt is \.\COM1.
I did the following test in PowerShell:
[System.IO.Path]::GetFullPath('CON.TXT')==>C:\Users\{UserName}\CON.TXT[System.IO.Path]::GetFullPath('COM1.TXT\file1.txt')==>C:\Users\{UserName}\COM1.TXT\file1.txtPage URL
https://learn.microsoft.com/en-us/dotnet/standard/io/file-path-formats
Content source URL
https://github.com/dotnet/docs/blob/main/docs/standard/io/file-path-formats.md
Document Version Independent Id
716a28dc-360e-2964-47f5-0ff18bb00b1c
Article author
@adegeo
Metadata
Associated WorkItem - 275386
The text was updated successfully, but these errors were encountered: