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

[neild]

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]

cc @rsc @ianlancetaylor @bradfitz @griesemer

[qmuntal]

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.