Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.Sign up
syscall: windows doesn't allow read-only directories #35042
On Windows, right now we map the lack of the writable bit in Unix file permissions to FILE_ATTRIBUTES_READONLY. This sort of works fine, but MSDN says that it's not honored for directories. This has implications for the Go module cache.
I'm not suggesting that we change this mapping to something else right now, but in case things pop up down the line related to this, here's a bug to track it.
Hmm... At the very least, the documentation for
It notably does not mention any behavior for directories.
Windows files and directory permissions cannot be mapped onto Unix user/group/everyone + read/write/execute. Most Windows users don't care about file permissions - as long as their files inherit permissions of containing directories, most things just work. For anything unusual Windows Go users would have to use Windows APIs directly.
More documentation is not always better. If documentation is long, people won't read it.
But we should correct wrong documentation.
I'm in way over my head, but from what I can tell there may be a reasonable mapping of the unix “write” permission bit to the windows
Similarly, the execute bit might reasonably map to
(But none of that is to say that we should actually implement that mapping.)
Mapping Unix permission bits to Windows ACLs probably makes more sense than what we do now, which is mapping a single Unix permission bit to a "file attribute", which is not an ACL (and apparently doesn't work for directories either).
I think there probably would be a quasi coherent scheme we could come up with, for all of user, group, and world, and maybe even for the sticky bit. It would map better than what we currently have and would wind up supporting things like directories.
But it does certainly require more than a moment's thought. As with most things Windows, the devil is in the details.
The actual implementation would wind up looking something like:
func unixPermToSA(perm FileMode) *SECURITY_ATTRIBUTES
And then all of the various Windows file creation and retrieval functions will take or return a security attribute struct, which we're currently passing in as nil.
But, as I said, the devil is really in the details, and there are tons of unanswered questions. Then, let's say we get the mapping down. Do we want to emulate umask too? Probably, since people tend to pass in 0666 rather than 0644. So now we're doing umask emulation...
It all seems possible to do, but probably hard, and risky if it's not done right. So maybe this kind of project is best deferred until somebody actually complains compellingly about the status quo.