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 · 2 comments
Open

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

neild opened this issue Jan 30, 2025 · 2 comments
Labels
NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. OS-Windows
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

@qmuntal
Copy link
Member

qmuntal commented Mar 11, 2025

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.)

Read-only reparse points behave as read-only files: you can't modify its content or attributes. This means that it is not possible to change the link target without removing the read-only attribute. Example (using PowerShell):

> New-Item -Type SymbolicLink -Path link -Target foo
> attrib +r /l link # set the read-only attribute
> New-Item -Type SymbolicLink -Path link -Target foo2 -Force
New-Item: Access to the path 'link' is denied.
New-Item: Cannot create a file when that file already exists.
> attrib -r /l link # unset the read-only attribute
> New-Item -Type SymbolicLink -Path link -Target foo2 -Force
# Succeeds

Having said this, I'm fine changing Chmod to follows reparse points, if that's what users would expect.

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. OS-Windows
Projects
None yet
Development

No branches or pull requests

4 participants