Fix `Test-Path -IsValid` to check for invalid path and filename characters #21358

SteveL-MSFT · 2024-03-20T19:50:32Z

PR Summary

Due to intentional breaking change in .NET, Test-Path -IsValid no longer fails for some filenames which used to fail.

Fix is to use .NET GetInvalidPathChars() and GetInvalidFilenameChars() to perform additional check within the FileSystemProvider to validate if the path is valid for the current OS.

PR Context

Fix #20847

PR Checklist

pull-request-quantifier-deprecated · 2024-03-20T19:50:37Z

This PR has 6 quantified lines of changes. In general, a change size of upto 200 lines is ideal for the best PR experience!

Quantification details

Label      : Extra Small
Size       : +6 -0
Percentile : 2.4%

Total files changed: 2

Change summary by file extension:
.cs : +2 -0
.ps1 : +4 -0

Why proper sizing of changes matters

Optimal pull request sizes drive a better predictable PR flow as they strike a
balance between between PR complexity and PR review overhead. PRs within the
optimal size (typical small, or medium sized PRs) mean:

Fast and predictable releases to production:
- Optimal size changes are more likely to be reviewed faster with fewer
  iterations.
- Similarity in low PR complexity drives similar review times.
Review quality is likely higher as complexity is lower:
- Bugs are more likely to be detected.
- Code inconsistencies are more likely to be detected.
Knowledge sharing is improved within the participants:
- Small portions can be assimilated better.
Better engineering practices are exercised:
- Solving big problems by dividing them in well contained, smaller problems.
- Exercising separation of concerns within the code changes.

What can I do to optimize my changes

Use the PullRequestQuantifier to quantify your PR accurately
- Create a context profile for your repo using the context generator
- Exclude files that are not necessary to be reviewed or do not increase the review complexity. Example: Autogenerated code, docs, project IDE setting files, binaries, etc. Check out the Excluded section from your prquantifier.yaml context profile.
- Understand your typical change complexity, drive towards the desired complexity by adjusting the label mapping in your prquantifier.yaml context profile.
- Only use the labels that matter to you, see context specification to customize your prquantifier.yaml context profile.
Change your engineering behaviors
- For PRs that fall outside of the desired spectrum, review the details and check if:
  - Your PR could be split in smaller, self-contained PRs instead
  - Your PR only solves one particular issue. (For example, don't refactor and code new features in the same PR).

How to interpret the change counts in git diff output

One line was added: +1 -0
One line was deleted: +0 -1
One line was modified: +1 -1 (git diff doesn't know about modified, it will
interpret that line like one addition plus one deletion)
Change percentiles: Change characteristics (addition, deletion, modification)
of this PR in relation to all other PRs within the repository.

Was this comment helpful? 👍 :ok_hand: :thumbsdown: (Email)
Customize PullRequestQuantifier for this repository.

pull-request-quantifier-deprecated · 2024-03-20T21:50:48Z

This PR has 6 quantified lines of changes. In general, a change size of upto 200 lines is ideal for the best PR experience!

Quantification details

Label      : Extra Small
Size       : +6 -0
Percentile : 2.4%

Total files changed: 2

Change summary by file extension:
.cs : +2 -0
.ps1 : +4 -0

Why proper sizing of changes matters

Optimal pull request sizes drive a better predictable PR flow as they strike a
balance between between PR complexity and PR review overhead. PRs within the
optimal size (typical small, or medium sized PRs) mean:

Fast and predictable releases to production:
- Optimal size changes are more likely to be reviewed faster with fewer
  iterations.
- Similarity in low PR complexity drives similar review times.
Review quality is likely higher as complexity is lower:
- Bugs are more likely to be detected.
- Code inconsistencies are more likely to be detected.
Knowledge sharing is improved within the participants:
- Small portions can be assimilated better.
Better engineering practices are exercised:
- Solving big problems by dividing them in well contained, smaller problems.
- Exercising separation of concerns within the code changes.

What can I do to optimize my changes

Use the PullRequestQuantifier to quantify your PR accurately
- Create a context profile for your repo using the context generator
- Exclude files that are not necessary to be reviewed or do not increase the review complexity. Example: Autogenerated code, docs, project IDE setting files, binaries, etc. Check out the Excluded section from your prquantifier.yaml context profile.
- Understand your typical change complexity, drive towards the desired complexity by adjusting the label mapping in your prquantifier.yaml context profile.
- Only use the labels that matter to you, see context specification to customize your prquantifier.yaml context profile.
Change your engineering behaviors
- For PRs that fall outside of the desired spectrum, review the details and check if:
  - Your PR could be split in smaller, self-contained PRs instead
  - Your PR only solves one particular issue. (For example, don't refactor and code new features in the same PR).

How to interpret the change counts in git diff output

One line was added: +1 -0
One line was deleted: +0 -1
One line was modified: +1 -1 (git diff doesn't know about modified, it will
interpret that line like one addition plus one deletion)
Change percentiles: Change characteristics (addition, deletion, modification)
of this PR in relation to all other PRs within the repository.

Was this comment helpful? 👍 :ok_hand: :thumbsdown: (Email)
Customize PullRequestQuantifier for this repository.

test/powershell/Modules/Microsoft.PowerShell.Management/Test-Path.Tests.ps1

src/System.Management.Automation/namespaces/FileSystemProvider.cs

pull-request-quantifier-deprecated · 2024-03-25T17:56:01Z

This PR has 39 quantified lines of changes. In general, a change size of upto 200 lines is ideal for the best PR experience!

Quantification details

Label      : Extra Small
Size       : +39 -0
Percentile : 15.6%

Total files changed: 2

Change summary by file extension:
.cs : +5 -0
.ps1 : +34 -0

Why proper sizing of changes matters

Optimal pull request sizes drive a better predictable PR flow as they strike a
balance between between PR complexity and PR review overhead. PRs within the
optimal size (typical small, or medium sized PRs) mean:

Fast and predictable releases to production:
- Optimal size changes are more likely to be reviewed faster with fewer
  iterations.
- Similarity in low PR complexity drives similar review times.
Review quality is likely higher as complexity is lower:
- Bugs are more likely to be detected.
- Code inconsistencies are more likely to be detected.
Knowledge sharing is improved within the participants:
- Small portions can be assimilated better.
Better engineering practices are exercised:
- Solving big problems by dividing them in well contained, smaller problems.
- Exercising separation of concerns within the code changes.

What can I do to optimize my changes

Use the PullRequestQuantifier to quantify your PR accurately
- Create a context profile for your repo using the context generator
- Exclude files that are not necessary to be reviewed or do not increase the review complexity. Example: Autogenerated code, docs, project IDE setting files, binaries, etc. Check out the Excluded section from your prquantifier.yaml context profile.
- Understand your typical change complexity, drive towards the desired complexity by adjusting the label mapping in your prquantifier.yaml context profile.
- Only use the labels that matter to you, see context specification to customize your prquantifier.yaml context profile.
Change your engineering behaviors
- For PRs that fall outside of the desired spectrum, review the details and check if:
  - Your PR could be split in smaller, self-contained PRs instead
  - Your PR only solves one particular issue. (For example, don't refactor and code new features in the same PR).

How to interpret the change counts in git diff output

One line was added: +1 -0
One line was deleted: +0 -1
One line was modified: +1 -1 (git diff doesn't know about modified, it will
interpret that line like one addition plus one deletion)
Change percentiles: Change characteristics (addition, deletion, modification)
of this PR in relation to all other PRs within the repository.

Was this comment helpful? 👍 :ok_hand: :thumbsdown: (Email)
Customize PullRequestQuantifier for this repository.

pull-request-quantifier-deprecated · 2024-03-25T18:06:11Z

This PR has 39 quantified lines of changes. In general, a change size of upto 200 lines is ideal for the best PR experience!

Quantification details

Label      : Extra Small
Size       : +39 -0
Percentile : 15.6%

Total files changed: 2

Change summary by file extension:
.cs : +5 -0
.ps1 : +34 -0

Why proper sizing of changes matters

Optimal pull request sizes drive a better predictable PR flow as they strike a
balance between between PR complexity and PR review overhead. PRs within the
optimal size (typical small, or medium sized PRs) mean:

Fast and predictable releases to production:
- Optimal size changes are more likely to be reviewed faster with fewer
  iterations.
- Similarity in low PR complexity drives similar review times.
Review quality is likely higher as complexity is lower:
- Bugs are more likely to be detected.
- Code inconsistencies are more likely to be detected.
Knowledge sharing is improved within the participants:
- Small portions can be assimilated better.
Better engineering practices are exercised:
- Solving big problems by dividing them in well contained, smaller problems.
- Exercising separation of concerns within the code changes.

What can I do to optimize my changes

Use the PullRequestQuantifier to quantify your PR accurately
- Create a context profile for your repo using the context generator
- Exclude files that are not necessary to be reviewed or do not increase the review complexity. Example: Autogenerated code, docs, project IDE setting files, binaries, etc. Check out the Excluded section from your prquantifier.yaml context profile.
- Understand your typical change complexity, drive towards the desired complexity by adjusting the label mapping in your prquantifier.yaml context profile.
- Only use the labels that matter to you, see context specification to customize your prquantifier.yaml context profile.
Change your engineering behaviors
- For PRs that fall outside of the desired spectrum, review the details and check if:
  - Your PR could be split in smaller, self-contained PRs instead
  - Your PR only solves one particular issue. (For example, don't refactor and code new features in the same PR).

How to interpret the change counts in git diff output

One line was added: +1 -0
One line was deleted: +0 -1
One line was modified: +1 -1 (git diff doesn't know about modified, it will
interpret that line like one addition plus one deletion)
Change percentiles: Change characteristics (addition, deletion, modification)
of this PR in relation to all other PRs within the repository.

Was this comment helpful? 👍 :ok_hand: :thumbsdown: (Email)
Customize PullRequestQuantifier for this repository.

src/System.Management.Automation/namespaces/FileSystemProvider.cs

pull-request-quantifier-deprecated · 2024-03-25T20:49:11Z

This PR has 41 quantified lines of changes. In general, a change size of upto 200 lines is ideal for the best PR experience!

Quantification details

Label      : Extra Small
Size       : +41 -0
Percentile : 16.4%

Total files changed: 2

Change summary by file extension:
.cs : +7 -0
.ps1 : +34 -0

Why proper sizing of changes matters

Optimal pull request sizes drive a better predictable PR flow as they strike a
balance between between PR complexity and PR review overhead. PRs within the
optimal size (typical small, or medium sized PRs) mean:

Fast and predictable releases to production:
- Optimal size changes are more likely to be reviewed faster with fewer
  iterations.
- Similarity in low PR complexity drives similar review times.
Review quality is likely higher as complexity is lower:
- Bugs are more likely to be detected.
- Code inconsistencies are more likely to be detected.
Knowledge sharing is improved within the participants:
- Small portions can be assimilated better.
Better engineering practices are exercised:
- Solving big problems by dividing them in well contained, smaller problems.
- Exercising separation of concerns within the code changes.

What can I do to optimize my changes

Use the PullRequestQuantifier to quantify your PR accurately
- Create a context profile for your repo using the context generator
- Exclude files that are not necessary to be reviewed or do not increase the review complexity. Example: Autogenerated code, docs, project IDE setting files, binaries, etc. Check out the Excluded section from your prquantifier.yaml context profile.
- Understand your typical change complexity, drive towards the desired complexity by adjusting the label mapping in your prquantifier.yaml context profile.
- Only use the labels that matter to you, see context specification to customize your prquantifier.yaml context profile.
Change your engineering behaviors
- For PRs that fall outside of the desired spectrum, review the details and check if:
  - Your PR could be split in smaller, self-contained PRs instead
  - Your PR only solves one particular issue. (For example, don't refactor and code new features in the same PR).

How to interpret the change counts in git diff output

One line was added: +1 -0
One line was deleted: +0 -1
One line was modified: +1 -1 (git diff doesn't know about modified, it will
interpret that line like one addition plus one deletion)
Change percentiles: Change characteristics (addition, deletion, modification)
of this PR in relation to all other PRs within the repository.

Was this comment helpful? 👍 :ok_hand: :thumbsdown: (Email)
Customize PullRequestQuantifier for this repository.

jborean93 · 2024-03-25T22:10:12Z

@SteveL-MSFT it seems like something is up with the Windows and Linux builds in CI. https://dev.azure.com/powershell/PowerShell/_build?definitionId=19 and https://dev.azure.com/powershell/PowerShell/_build?definitionId=17 have no run since Sunday and this PR (plus others I've seen open since) only seems to be running the macOS tests.

pull-request-quantifier-deprecated · 2024-03-25T22:20:33Z

This PR has 41 quantified lines of changes. In general, a change size of upto 200 lines is ideal for the best PR experience!

Quantification details

Label      : Extra Small
Size       : +41 -0
Percentile : 16.4%

Total files changed: 2

Change summary by file extension:
.cs : +7 -0
.ps1 : +34 -0

Why proper sizing of changes matters

Optimal pull request sizes drive a better predictable PR flow as they strike a
balance between between PR complexity and PR review overhead. PRs within the
optimal size (typical small, or medium sized PRs) mean:

Fast and predictable releases to production:
- Optimal size changes are more likely to be reviewed faster with fewer
  iterations.
- Similarity in low PR complexity drives similar review times.
Review quality is likely higher as complexity is lower:
- Bugs are more likely to be detected.
- Code inconsistencies are more likely to be detected.
Knowledge sharing is improved within the participants:
- Small portions can be assimilated better.
Better engineering practices are exercised:
- Solving big problems by dividing them in well contained, smaller problems.
- Exercising separation of concerns within the code changes.

What can I do to optimize my changes

Use the PullRequestQuantifier to quantify your PR accurately
- Create a context profile for your repo using the context generator
- Exclude files that are not necessary to be reviewed or do not increase the review complexity. Example: Autogenerated code, docs, project IDE setting files, binaries, etc. Check out the Excluded section from your prquantifier.yaml context profile.
- Understand your typical change complexity, drive towards the desired complexity by adjusting the label mapping in your prquantifier.yaml context profile.
- Only use the labels that matter to you, see context specification to customize your prquantifier.yaml context profile.
Change your engineering behaviors
- For PRs that fall outside of the desired spectrum, review the details and check if:
  - Your PR could be split in smaller, self-contained PRs instead
  - Your PR only solves one particular issue. (For example, don't refactor and code new features in the same PR).

How to interpret the change counts in git diff output

One line was added: +1 -0
One line was deleted: +0 -1
One line was modified: +1 -1 (git diff doesn't know about modified, it will
interpret that line like one addition plus one deletion)
Change percentiles: Change characteristics (addition, deletion, modification)
of this PR in relation to all other PRs within the repository.

Was this comment helpful? 👍 :ok_hand: :thumbsdown: (Email)
Customize PullRequestQuantifier for this repository.

SteveL-MSFT · 2024-03-25T23:09:46Z

@jborean93 yes, we've noticed that and working on it

pull-request-quantifier-deprecated · 2024-03-25T23:29:09Z

This PR has 41 quantified lines of changes. In general, a change size of upto 200 lines is ideal for the best PR experience!

Quantification details

Label      : Extra Small
Size       : +41 -0
Percentile : 16.4%

Total files changed: 2

Change summary by file extension:
.cs : +7 -0
.ps1 : +34 -0

Why proper sizing of changes matters

Optimal pull request sizes drive a better predictable PR flow as they strike a
balance between between PR complexity and PR review overhead. PRs within the
optimal size (typical small, or medium sized PRs) mean:

Fast and predictable releases to production:
- Optimal size changes are more likely to be reviewed faster with fewer
  iterations.
- Similarity in low PR complexity drives similar review times.
Review quality is likely higher as complexity is lower:
- Bugs are more likely to be detected.
- Code inconsistencies are more likely to be detected.
Knowledge sharing is improved within the participants:
- Small portions can be assimilated better.
Better engineering practices are exercised:
- Solving big problems by dividing them in well contained, smaller problems.
- Exercising separation of concerns within the code changes.

What can I do to optimize my changes

Use the PullRequestQuantifier to quantify your PR accurately
- Create a context profile for your repo using the context generator
- Exclude files that are not necessary to be reviewed or do not increase the review complexity. Example: Autogenerated code, docs, project IDE setting files, binaries, etc. Check out the Excluded section from your prquantifier.yaml context profile.
- Understand your typical change complexity, drive towards the desired complexity by adjusting the label mapping in your prquantifier.yaml context profile.
- Only use the labels that matter to you, see context specification to customize your prquantifier.yaml context profile.
Change your engineering behaviors
- For PRs that fall outside of the desired spectrum, review the details and check if:
  - Your PR could be split in smaller, self-contained PRs instead
  - Your PR only solves one particular issue. (For example, don't refactor and code new features in the same PR).

How to interpret the change counts in git diff output

One line was added: +1 -0
One line was deleted: +0 -1
One line was modified: +1 -1 (git diff doesn't know about modified, it will
interpret that line like one addition plus one deletion)
Change percentiles: Change characteristics (addition, deletion, modification)
of this PR in relation to all other PRs within the repository.

Was this comment helpful? 👍 :ok_hand: :thumbsdown: (Email)
Customize PullRequestQuantifier for this repository.

src/System.Management.Automation/namespaces/FileSystemProvider.cs

…tion

pull-request-quantifier-deprecated · 2024-03-26T16:22:28Z

This PR has 37 quantified lines of changes. In general, a change size of upto 200 lines is ideal for the best PR experience!

Quantification details

Label      : Extra Small
Size       : +37 -0
Percentile : 14.8%

Total files changed: 2

Change summary by file extension:
.cs : +3 -0
.ps1 : +34 -0

Why proper sizing of changes matters

Optimal pull request sizes drive a better predictable PR flow as they strike a
balance between between PR complexity and PR review overhead. PRs within the
optimal size (typical small, or medium sized PRs) mean:

Fast and predictable releases to production:
- Optimal size changes are more likely to be reviewed faster with fewer
  iterations.
- Similarity in low PR complexity drives similar review times.
Review quality is likely higher as complexity is lower:
- Bugs are more likely to be detected.
- Code inconsistencies are more likely to be detected.
Knowledge sharing is improved within the participants:
- Small portions can be assimilated better.
Better engineering practices are exercised:
- Solving big problems by dividing them in well contained, smaller problems.
- Exercising separation of concerns within the code changes.

What can I do to optimize my changes

Use the PullRequestQuantifier to quantify your PR accurately
- Create a context profile for your repo using the context generator
- Exclude files that are not necessary to be reviewed or do not increase the review complexity. Example: Autogenerated code, docs, project IDE setting files, binaries, etc. Check out the Excluded section from your prquantifier.yaml context profile.
- Understand your typical change complexity, drive towards the desired complexity by adjusting the label mapping in your prquantifier.yaml context profile.
- Only use the labels that matter to you, see context specification to customize your prquantifier.yaml context profile.
Change your engineering behaviors
- For PRs that fall outside of the desired spectrum, review the details and check if:
  - Your PR could be split in smaller, self-contained PRs instead
  - Your PR only solves one particular issue. (For example, don't refactor and code new features in the same PR).

How to interpret the change counts in git diff output

One line was added: +1 -0
One line was deleted: +0 -1
One line was modified: +1 -1 (git diff doesn't know about modified, it will
interpret that line like one addition plus one deletion)
Change percentiles: Change characteristics (addition, deletion, modification)
of this PR in relation to all other PRs within the repository.

Was this comment helpful? 👍 :ok_hand: :thumbsdown: (Email)
Customize PullRequestQuantifier for this repository.

pull-request-quantifier-deprecated · 2024-03-26T19:59:06Z

This PR has 37 quantified lines of changes. In general, a change size of upto 200 lines is ideal for the best PR experience!

Quantification details

Label      : Extra Small
Size       : +37 -0
Percentile : 14.8%

Total files changed: 2

Change summary by file extension:
.cs : +3 -0
.ps1 : +34 -0

Why proper sizing of changes matters

Optimal pull request sizes drive a better predictable PR flow as they strike a
balance between between PR complexity and PR review overhead. PRs within the
optimal size (typical small, or medium sized PRs) mean:

Fast and predictable releases to production:
- Optimal size changes are more likely to be reviewed faster with fewer
  iterations.
- Similarity in low PR complexity drives similar review times.
Review quality is likely higher as complexity is lower:
- Bugs are more likely to be detected.
- Code inconsistencies are more likely to be detected.
Knowledge sharing is improved within the participants:
- Small portions can be assimilated better.
Better engineering practices are exercised:
- Solving big problems by dividing them in well contained, smaller problems.
- Exercising separation of concerns within the code changes.

What can I do to optimize my changes

Use the PullRequestQuantifier to quantify your PR accurately
- Create a context profile for your repo using the context generator
- Exclude files that are not necessary to be reviewed or do not increase the review complexity. Example: Autogenerated code, docs, project IDE setting files, binaries, etc. Check out the Excluded section from your prquantifier.yaml context profile.
- Understand your typical change complexity, drive towards the desired complexity by adjusting the label mapping in your prquantifier.yaml context profile.
- Only use the labels that matter to you, see context specification to customize your prquantifier.yaml context profile.
Change your engineering behaviors
- For PRs that fall outside of the desired spectrum, review the details and check if:
  - Your PR could be split in smaller, self-contained PRs instead
  - Your PR only solves one particular issue. (For example, don't refactor and code new features in the same PR).

How to interpret the change counts in git diff output

One line was added: +1 -0
One line was deleted: +0 -1
One line was modified: +1 -1 (git diff doesn't know about modified, it will
interpret that line like one addition plus one deletion)
Change percentiles: Change characteristics (addition, deletion, modification)
of this PR in relation to all other PRs within the repository.

Was this comment helpful? 👍 :ok_hand: :thumbsdown: (Email)
Customize PullRequestQuantifier for this repository.

JamesWTruher · 2024-04-01T22:31:21Z

src/System.Management.Automation/namespaces/FileSystemProvider.cs

+            // Remove drive root first
+            string pathWithoutDriveRoot = path.Substring(Path.GetPathRoot(path).Length);
+
+            foreach (string segment in pathWithoutDriveRoot.Split(Path.DirectorySeparatorChar))


i suppose it may be a toss up between this and:
pathWithoutDriveRoot.IndexOfAny(Path.GetInvalidFileNameChars().Except(Path.DirectorySeparatorChar)) != 1)

i wondered if it might be faster to not split (but then, of course, there's the linq)

I think in general we want to use less Linq and not more. If there's a perf concern, it might be faster to just replace all the separators with a valid character and analyze the whole string at once, but at the expense of readability and only minor perf improvement I think

src/System.Management.Automation/namespaces/FileSystemProvider.cs

microsoft-github-policy-service · 2024-04-02T16:42:51Z

📣 Hey @SteveL-MSFT, how did we do? We would love to hear your feedback with the link below! 🗣️

🔗 https://aka.ms/PSRepoFeedback

adityapatwardhan · 2024-04-03T20:54:40Z

We will wait for a preview release before approving for 7.4.x

SteveL-MSFT requested a review from SeeminglyScience March 20, 2024 19:50

SteveL-MSFT assigned SeeminglyScience Mar 20, 2024

SteveL-MSFT requested a review from anmenaga as a code owner March 20, 2024 19:50

pull-request-quantifier-deprecated bot added the Extra Small label Mar 20, 2024

SteveL-MSFT added the BackPort-7.4.x-Consider label Mar 20, 2024

jborean93 reviewed Mar 20, 2024

View reviewed changes

test/powershell/Modules/Microsoft.PowerShell.Management/Test-Path.Tests.ps1 Outdated Show resolved Hide resolved

src/System.Management.Automation/namespaces/FileSystemProvider.cs Outdated Show resolved Hide resolved

SteveL-MSFT and others added 4 commits March 25, 2024 10:57

Fix Test-Path -IsValid to check for invalid characters

4bce454

add check of the filename

6ffa7c5

limit path check to directory

ccff28c

address Jordan's feedback to check each segment of the path

5f78260

SteveL-MSFT force-pushed the test-path branch from ec75bef to 5f78260 Compare March 25, 2024 17:57

fix case where it's only a filename

1a35cc9

jborean93 reviewed Mar 25, 2024

View reviewed changes

src/System.Management.Automation/namespaces/FileSystemProvider.cs Outdated Show resolved Hide resolved

change to use GetInvalidFilenameChars() for both path and filename

758c7d1

change test to use variant name so there isn't a null within the output

9705a60

iSazonov reviewed Mar 26, 2024

View reviewed changes

src/System.Management.Automation/namespaces/FileSystemProvider.cs Outdated Show resolved Hide resolved

address Ilya's feedback, no need to separate filename and path valida…

9686144

…tion

daxian-dbw added the CL-General Indicates that a PR should be marked as a general cmdlet change in the Change Log label Mar 26, 2024

daxian-dbw closed this Mar 26, 2024

daxian-dbw reopened this Mar 26, 2024

remove path root before checking segments

7fe1609

JamesWTruher reviewed Apr 1, 2024

View reviewed changes

daxian-dbw approved these changes Apr 1, 2024

View reviewed changes

src/System.Management.Automation/namespaces/FileSystemProvider.cs Outdated Show resolved Hide resolved

Steve Lee (POWERSHELL HE/HIM) (from Dev Box) and others added 2 commits April 1, 2024 15:35

add comment

12cc221

Avoid calling Path.GetInvalidFileNameChars for every segment.

32b9b7c

daxian-dbw approved these changes Apr 1, 2024

View reviewed changes

daxian-dbw merged commit 371ceff into PowerShell:master Apr 2, 2024
36 checks passed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Fix `Test-Path -IsValid` to check for invalid path and filename characters #21358

Fix `Test-Path -IsValid` to check for invalid path and filename characters #21358

SteveL-MSFT commented Mar 20, 2024 •

edited

pull-request-quantifier-deprecated bot commented Mar 20, 2024

What can I do to optimize my changes

How to interpret the change counts in git diff output

pull-request-quantifier-deprecated bot commented Mar 20, 2024

What can I do to optimize my changes

How to interpret the change counts in git diff output

pull-request-quantifier-deprecated bot commented Mar 25, 2024

What can I do to optimize my changes

How to interpret the change counts in git diff output

pull-request-quantifier-deprecated bot commented Mar 25, 2024

What can I do to optimize my changes

How to interpret the change counts in git diff output

pull-request-quantifier-deprecated bot commented Mar 25, 2024

What can I do to optimize my changes

How to interpret the change counts in git diff output

jborean93 commented Mar 25, 2024 •

edited by unfurl-links bot

pull-request-quantifier-deprecated bot commented Mar 25, 2024

What can I do to optimize my changes

How to interpret the change counts in git diff output

SteveL-MSFT commented Mar 25, 2024

pull-request-quantifier-deprecated bot commented Mar 25, 2024

What can I do to optimize my changes

How to interpret the change counts in git diff output

pull-request-quantifier-deprecated bot commented Mar 26, 2024

What can I do to optimize my changes

How to interpret the change counts in git diff output

pull-request-quantifier-deprecated bot commented Mar 26, 2024

What can I do to optimize my changes

How to interpret the change counts in git diff output

JamesWTruher Apr 1, 2024

SteveL-MSFT Apr 1, 2024 •

edited

microsoft-github-policy-service bot commented Apr 2, 2024 •

edited by unfurl-links bot

adityapatwardhan commented Apr 3, 2024

Fix Test-Path -IsValid to check for invalid path and filename characters #21358

Fix Test-Path -IsValid to check for invalid path and filename characters #21358

Conversation

SteveL-MSFT commented Mar 20, 2024 • edited

PR Summary

PR Context

PR Checklist

pull-request-quantifier-deprecated bot commented Mar 20, 2024

What can I do to optimize my changes

How to interpret the change counts in git diff output

pull-request-quantifier-deprecated bot commented Mar 20, 2024

What can I do to optimize my changes

How to interpret the change counts in git diff output

pull-request-quantifier-deprecated bot commented Mar 25, 2024

What can I do to optimize my changes

How to interpret the change counts in git diff output

pull-request-quantifier-deprecated bot commented Mar 25, 2024

What can I do to optimize my changes

How to interpret the change counts in git diff output

pull-request-quantifier-deprecated bot commented Mar 25, 2024

What can I do to optimize my changes

How to interpret the change counts in git diff output

jborean93 commented Mar 25, 2024 • edited by unfurl-links bot

pull-request-quantifier-deprecated bot commented Mar 25, 2024

What can I do to optimize my changes

How to interpret the change counts in git diff output

SteveL-MSFT commented Mar 25, 2024

pull-request-quantifier-deprecated bot commented Mar 25, 2024

What can I do to optimize my changes

How to interpret the change counts in git diff output

pull-request-quantifier-deprecated bot commented Mar 26, 2024

What can I do to optimize my changes

How to interpret the change counts in git diff output

pull-request-quantifier-deprecated bot commented Mar 26, 2024

What can I do to optimize my changes

How to interpret the change counts in git diff output

JamesWTruher Apr 1, 2024

Choose a reason for hiding this comment

SteveL-MSFT Apr 1, 2024 • edited

Choose a reason for hiding this comment

microsoft-github-policy-service bot commented Apr 2, 2024 • edited by unfurl-links bot

adityapatwardhan commented Apr 3, 2024

Fix `Test-Path -IsValid` to check for invalid path and filename characters #21358

Fix `Test-Path -IsValid` to check for invalid path and filename characters #21358

SteveL-MSFT commented Mar 20, 2024 •

edited

jborean93 commented Mar 25, 2024 •

edited by unfurl-links bot

SteveL-MSFT Apr 1, 2024 •

edited

microsoft-github-policy-service bot commented Apr 2, 2024 •

edited by unfurl-links bot