Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

UNC and other DOS Device Paths unusable #348

Open
CryZe opened this issue Jan 29, 2024 · 1 comment
Open

UNC and other DOS Device Paths unusable #348

CryZe opened this issue Jan 29, 2024 · 1 comment

Comments

@CryZe
Copy link

CryZe commented Jan 29, 2024

The following logic:

let wide_final = if wide.starts_with(&['\\' as u16, '\\' as _, '?' as _, '\\' as _]) {
&wide[4..]
} else {
&wide
};

completely breaks DOS device UNC paths such as:

\\?\UNC\server\share\bar.exe

which would have to be translated to:

\\server\share\bar.exe

in addition to that, other DOS device paths such as:

\\?\Volume{b75e2c83-0000-0000-0000-602f00000000}\Test\Foo.txt

get completely ruined.

There also is a lack of \\.\ handling. I'm also not sure why this gets stripped in the first place, join can handle these paths just fine.

@sunfishcode
Copy link
Member

cap-std on Windows implements "openat" by concatenating the path of the base directory with the user-provided relative path, so it gets into weird situations when the user-provided path is in a different format from the base. In theory this is fixable, but I spent some time trying to figure out Windows paths and failed so many times that I'm not eager to try it again. Another possible path forward is to migrate more of the code to NtCreateFile, which some parts of cap-std now use, but not all yet.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants