@DHowett Have you any thoughts about blocking CONIN$ and CONOUT$ in PowerShell file operations?
Copy-Item <text file> CONOUT$ works like Get-Content and this looks good and we could expect copy-item CONIN$ <file path> works too but no. Also we have New-Item and others and this force us to think that we should follow the best practice and block these reserved names.
In my opinion, we should ban these names in order to eliminate misunderstandings and unjustified expectations.

Yeah, we're already blocking the majority of them, so probably it would make sense to block all of them.

Maybe a subset of them could be useful for specific provider cmdlets, but I don't think any of them would be universally useful for all the provider cmdlets to support.

So, here's the thing that worries me about the windows reserved names.

I don't know how we handle them in a world where pwsh also runs on Linux (and can access /dev/sda1, or /dev/fd/0 which is a lot like CONOUT$) and macOS (/dev/rdisk0, /dev/tty).

Do we have a holistic story that covers how powershell handles devicelike file handles in general? If not, is this just putting a band-aid over a problem?

But, here: We should block these names.

There are better ways to write output to the console or read input from the console. It is generally a bad thing that we would allow PowerShell users -- users who have opted into a higher-level abstraction -- direct unmanaged access to the raw I/O handles.

CMD should be able to do it. Perhaps PowerShell should bend users towards using the object model instead.

/cc @SteveL-MSFT not sure who best to answer @DHowett's question regarding similarly reserved names on MacOS/Linux, but maybe worth opening an issue for? 🤔

Otherwise... yep, agreed. 🙂

Do we have a holistic story that covers how powershell handles devicelike file handles in general? If not, is this just putting a band-aid over a problem?

We follow the naming convention https://docs.microsoft.com/en-us/windows/win32/fileio/naming-a-file#naming-conventions but CONIN$/CONOUT$ is not documented there.

I don't know how we handle them in a world where pwsh also runs on Linux (and can access /dev/sda1, or /dev/fd/0 which is a lot like CONOUT$) and macOS (/dev/rdisk0, /dev/tty).

In Unix-s they are files. Users could do cd ~; mkdir /dev/sda1 and access this by cat ./dev/sda1. But in Windows ./ prefix optional and users can do type CONOUT$ and it is not clear whether this a file or a device.

Naming Files, Paths, and Namespaces - Win32 apps

All file systems supported by Windows use the concept of files and directories to access data stored on a disk or device.

This pull request has been automatically marked as Review Needed because it has been there has not been any activity for 7 days.
Maintainer, please provide feedback and/or mark it as Waiting on Author

@anmenaga The PR is ready to merge.

@davidreis97 Thanks for your contribution!