Validate full path of file instead of file name in parsing /resource args#27279
Validate full path of file instead of file name in parsing /resource args#27279OmarTawfik merged 3 commits intodotnet:masterfrom OmarTawfik:bugs/27045/path-too-long
Conversation
|
approved #Resolved |
| /// <param name="path"></param> | ||
| /// <returns></returns> | ||
| public static bool IsValidFilePath(string path) | ||
| public static bool IsValidFilePath(string fullPath) |
There was a problem hiding this comment.
public static bool IsValidFilePath(string fullPath) [](start = 8, length = 51)
Would it be valid to add an assert Debug.Assert(IsAbsolute(fullPath));? #Closed
There was a problem hiding this comment.
| return null; | ||
| } | ||
|
|
||
| if (fullPath == null || !PathUtilities.IsValidFilePath(fileName)) |
There was a problem hiding this comment.
fullPath == null [](start = 16, length = 16)
No need to check for null? #Closed
There was a problem hiding this comment.
| Return Nothing | ||
| End If | ||
|
|
||
| If fullPath Is Nothing OrElse Not PathUtilities.IsValidFilePath(fileName) Then |
There was a problem hiding this comment.
fullPath Is Nothing OrElse [](start = 15, length = 27)
No need to check for null? #Closed
There was a problem hiding this comment.
|
Done with review pass (iteration 1) #Closed |
|
@AlekseyTs commented out your suggestion because of an existing bug. |
Fixes #27045
The original bug is that the file name was checked instead of the full path. This makes the
FileInfoconstructor consider the execution path as the base path for the (relative) file name.This change has no tests associated, as I talked with a couple of people on the team, and I believe this case is exteremely hard to put in a unit test, as the test needs to move the executed tests/compiler somewhere long enough to repro, and the scenario is corner case enough I don't think it is worth modifying the test harness at this point.