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

os: on Windows, Chmod acts on symlinks rather than the symlink target #71492

Open
neild opened this issue Jan 30, 2025 · 1 comment
Open

os: on Windows, Chmod acts on symlinks rather than the symlink target #71492

neild opened this issue Jan 30, 2025 · 1 comment
Labels
NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Milestone

Comments

@neild
Copy link
Contributor

neild commented Jan 30, 2025

Given a symlink "symlink" pointing to "file", on Unix systems os.Chmod("symlink", mode) will change the mode of "file".

On Windows, it will change the mode of "symlink". The only mode bit Chmod pays attention to on Windows is 0o200 (user-writable), which it uses to set the FILE_ATTRIBUTE_READONLY attribute. So far as I can tell, setting FILE_ATTRIBUTE_READONLY on a symlink doesn't seem to do much. (It might prevent changing the link target? It doesn't prevent writing to the linked-to file, however.)

I have no idea what we should be doing here, but I suppose maximum consistency with Unix would be to resolve symlinks and apply the attribute change to the link target.

I discovered this while implementing os.Root.Chmod on Windows, where I need to decide between being consistent with the current os.Chmod behavior on Windows or consistent with the Unix behavior.

/cc @qmuntal

@cagedmantis cagedmantis added NeedsFix The path to resolution is known, but the work has not been done. NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. and removed NeedsFix The path to resolution is known, but the work has not been done. labels Jan 31, 2025
@cagedmantis cagedmantis added this to the Backlog milestone Jan 31, 2025
@cagedmantis
Copy link
Contributor

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Projects
None yet
Development

No branches or pull requests

2 participants