Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

path/filepath: COM0 and LPT0 are now reserved on Windows #67245

Open
neild opened this issue May 7, 2024 · 8 comments
Open

path/filepath: COM0 and LPT0 are now reserved on Windows #67245

neild opened this issue May 7, 2024 · 8 comments
Labels
NeedsDecision Feedback is required from experts, contributors, and/or the community before a change can be made. OS-Windows
Milestone

Comments

@neild
Copy link
Contributor

neild commented May 7, 2024

https://learn.microsoft.com/en-us/windows/win32/fileio/naming-a-file states that COM0 and LPT0 are reserved names. I believe that this page used to only list COM[1-9] and LPT[1-9] as reserved, and empirically these names are available for use on the Windows versions I've tested.

We need to decide whether filepath.IsLocal should consider these names local or not.

In favor of filepath.IsLocal("COM0")==false: Current behavior, empirically you can create a file named COM0.

In favor of filepath.IsLocal("COM0")==true: Documented as a reserved name.

@ianlancetaylor
Copy link
Contributor

CC @golang/windows

@bjorndm
Copy link

bjorndm commented May 8, 2024

https://learn.microsoft.com/en-us/windows/win32/fileio/naming-a-file#win32-file-namespaces

It seems very complex. Since these are aliases, on a computer without serial or parallel ports these file names can be created, but it is not portable.

@neild
Copy link
Contributor Author

neild commented May 8, 2024

Huh. I wonder if the reference to COM0 is a typo in https://learn.microsoft.com/en-us/windows/win32/fileio/naming-a-file#win32-file-namespaces.

I don't understand how any of this works under the hood, but there's some form of special consideration given to the names COM[1-2¹²³], regardless of whether there's an associated serial port, but not for COM0.

@cherrymui cherrymui added the NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. label May 8, 2024
@cherrymui cherrymui added this to the Backlog milestone May 8, 2024
@cherrymui cherrymui added NeedsDecision Feedback is required from experts, contributors, and/or the community before a change can be made. recurring Issues that should never be closed, but moved to the next milestone once fixed in the current one. and removed NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. recurring Issues that should never be closed, but moved to the next milestone once fixed in the current one. labels May 8, 2024
@bjorndm
Copy link

bjorndm commented May 8, 2024

Maybe someone could test with a few USB to serial adapters and see what COM number gets assigned? Or even better , on a desktop with a serial PCI extension board? If COM0 never gets assigned in practice, we can keep this as it is now.

@alexbrainman
Copy link
Member

https://learn.microsoft.com/en-us/windows/win32/fileio/naming-a-file states that COM0 and LPT0 are reserved names. I believe that this page used to only list COM[1-9] and LPT[1-9] as reserved, and empirically these names are available for use on the Windows versions I've tested.

Agree. This matches my experience. COM[1-9] and LPT[1-9] are reserved names on Windows, and should only be used to refer to existing serial or parallel ports.

Huh. I wonder if the reference to COM0 is a typo in https://learn.microsoft.com/en-us/windows/win32/fileio/naming-a-file#win32-file-namespaces.

I don't see COM0 mentioned in https://learn.microsoft.com/en-us/windows/win32/fileio/naming-a-file#win32-file-namespaces section.

I don't understand how any of this works under the hood, ...

Same here. Perhaps other Windows developers know more.

Alex

@qmuntal
Copy link
Contributor

qmuntal commented May 12, 2024

I believe that this page used to only list COM[1-9] and LPT[1-9] as reserved

True, LPT0 and COM0 were added two years ago (by a non-Microsoft contributor): MicrosoftDocs/win32@2274ec1.

A more recent commit in that same file suggests that those names might be valid file names: MicrosoftDocs/win32@b4c2d78

Tangentially, COM0 and LPT0 are in practice treated as normal file names, contrary to documentation; I have not changed this as it's not clear whether they're still reserved for future use or just in case.

I'm on leave now, so can't contact the owners to know the right answer.

@matloob
Copy link
Contributor

matloob commented May 31, 2024

That's really strange. We might want to undo the change to x/mod to exclude those names until we get better information. It's pretty concerning that the change was made by a non-Microsoft contributor but doesn't have more information in the commit message.

@neild
Copy link
Contributor Author

neild commented May 31, 2024

I think for path/filepath, we should stick with treating LPT0 and COM0 as non-reserved. Whether they're officially "reserved" or not, they're empirically available for use and I can't imagine Microsoft with their admirable commitment to backwards compatibility changing that at this point. All this behavior has been stable for decades.

I don't have an opinion on x/mod.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
NeedsDecision Feedback is required from experts, contributors, and/or the community before a change can be made. OS-Windows
Projects
None yet
Development

No branches or pull requests

7 participants