Fix path syntax handling #6768
Fix path syntax handling #6768
Conversation
|
Side notes: This should hopefully either fix or allow fixing usage of pipes with "bad" path characters (but valid pipe characters). This also will allow access to alternate data streams with device syntax. We'll still block with "standard" paths. (There isn't an efficient way to block them and not prevent access to valid device paths.) |
| && path[0] == '\\' | ||
| && (path[1] == '\\' || path[1] == '?') | ||
| && path[2] == '?' | ||
| && path[3] == '\\'; |
There was a problem hiding this comment.
So I guess the method is misnamed then? Based on your comments I'd assume a path like //?/C:/ is considered extended, but not normalized, hence will not skip normalization.
There was a problem hiding this comment.
This will return true for \??\... is that desired?
There was a problem hiding this comment.
Yes this is only for device paths that have "extended" behavior (e.g. they skip normalization and length checks). They have to be either \\?\ or \??\ exactly (can't have forward seps).
- Properly account for dos device paths - Remove unused path helpers - Remove all validation for extended paths - Recognize \??\ syntax - Handle device paths that get normalized
|
I've removed the "copy" constructors for StringBuffer and updated. |
|
Validated coverage and got signoff from @stephentoub offline. |
Fix path syntax handling Commit migrated from dotnet/corefx@17018f7
7 participants
\??\syntax@stephentoub, @ianhays, @ramarag, @Priya91, @terrajobst, @weshaggard