Support file redirection to local named pipe for external applications#27017
Support file redirection to local named pipe for external applications#27017jborean93 wants to merge 2 commits intoPowerShell:masterfrom
Conversation
Fixes the logic when opening a file for a redirected file path to ensure only 1 HANDLE is opened for local named pipes. This allows redirection to a named pipe where there is only 1 listener. Also optimizes the number of file HANDLES being opened from 3 to 2 for other files types.
There was a problem hiding this comment.
Pull request overview
This PR fixes file redirection to local named pipes (e.g., \\.\pipe\...) and mailslots for external applications in PowerShell on Windows. The root cause was that MasterStreamOpenImpl opened multiple file handles (via File.Exists and new FileInfo()) before the actual FileStream, which failed for named pipes that only allow one client connection. The fix detects named pipe/mailslot paths and skips the read-only attribute check, also optimizing regular files from 3 handle opens to 2 by removing the File.Exists call and relying on FileInfo.Attributes instead.
Changes:
- Skip the read-only file attribute check for Windows named pipes and mailslots to avoid opening extra handles
- Optimize regular file handling by replacing
File.Exists+FileInfowith justFileInfo(checkingAttributes != -1for existence) - Add comprehensive tests for named pipe and mailslot redirection scenarios
Reviewed changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated 1 comment.
| File | Description |
|---|---|
src/System.Management.Automation/utils/PathUtils.cs |
Detect named pipe/mailslot paths to skip read-only attribute checks; replace File.Exists with FileInfo.Attributes check |
test/powershell/Language/Parser/RedirectionOperator.Tests.ps1 |
Add tests for redirecting external application output to named pipes, mailslots, and case-insensitive pipe paths |
Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
|
This pull request has been automatically marked as Review Needed because it has been there has not been any activity for 7 days. |
PR Summary
Fixes the logic when opening a file for a redirected file path to ensure only 1 HANDLE is opened for local named pipes. This allows redirection to a named pipe where there is only 1 listener.
Also optimizes the number of file HANDLES being opened from 3 to 2 for other files types.
PR Context
Currently trying to redirect to a named pipe will result in the error
This is because the redirection setup will call
CreateFileWon the provided path 3 times with the first succeeding then the subsequent 2 fails as the named pipe no longer has an active server listener. This PR bypasses the readonly attribute tests for named pipes as they do not apply to those file types.While this fixes redirection from an external executable, redirecting from the normal output stream to a named pipe still fails with the same error. This is because the native command processor bypasses
Out-Fileto write the raw bytes directly whereas the normal file redirection goes throughOut-File -Path $redirectionPathand the provider APIOut-Filecalls will open the pipe handle as part of the-Pathglobbing matches. Maybe in the future this could also be solved but that's out of scope for this PR.Going into a bit more detail, redirection of non-external applications end up calling command.SessionState.Path.GetResolvedProviderPathFromPSPath(filePath, out provider) because
> $pathis compiled to| Out-File -Path $path. Something around this resolution is opening yet another HANDLE to the pipe causing the subsequent open operation later on to create the StreamWriter to fail as there are no more pipe instances to handle that. This could be solved in a few ways but as this PR is focused just on getting redirection working for external application redirection like can be done in cmd I didn't want to make it more complicated.PR Checklist
.h,.cpp,.cs,.ps1and.psm1files have the correct copyright header