os: Root ignores link type on Windows

[neild]

Windows makes a distinction between symlinks to a file and to a directory. A file link pointing to a directory cannot be traversed, nor can a directory link pointing to a file.

The os.Root type doesn't pay attention to link types when resolving files, however, and will follow links that Windows will not. It probably should behave consistently with the rest of the OS.

(See also #71165, which is the same issue in path/filepath.EvalSymlinks.)

[neild]

/cc @qmuntal

[gabyhelp]

Related Issues

• path/filepath: EvalSymlinks ignores link type on Windows #71165

_{(Emoji vote if this was helpful or unhelpful; more detailed feedback welcome in this discussion.)}

[neild]

Open question: How do you tell what kind of link an IO_REPARSE_TAG_SYMLINK reparse point is? I don't see anything in the reparse buffer that identifies it.

[qmuntal]

Open question: How do you tell what kind of link an IO_REPARSE_TAG_SYMLINK reparse point is? I don't see anything in the reparse buffer that identifies it.

We already know if an stat'ed symbolic links points to a directory, as we get this information in here:

go/src/os/types_windows.go

Lines 47 to 48 in 39f2032

	var d syscall.ByHandleFileInformation
	err = syscall.GetFileInformationByHandle(h, &d)

The problem is that FileInfo.Mode() doesn't set the ModeDir bit for symbolic links, so it difficult to know whether a symbolic link points to a directory or not:

go/src/os/types_windows.go

Lines 193 to 195 in 39f2032

	if !fs.isReparseTagNameSurrogate() {
	if fs.FileAttributes&syscall.FILE_ATTRIBUTE_DIRECTORY != 0 {
	m |= ModeDir | 0111

What does Unix do in this case? Does it set the S_ISDIR?

[ianlancetaylor]

In Unix a symbolic link is just a name forwarder. There is no difference between a link to a file and a link to a directory, and in fact you can change the destination from a file to a directory, or vice-versa, without affecting the symbolic link. So, no, a symbolic link will never have S_ISDIR set.

[neild]

To make things more confusing:

• link is a file link to dir.
• dir is a directory.
• dir\file is a file.

With this setup:

• os.Open("link") fails as expected (file link to directory)
• os.Open(`link\file`) opens dir\file successfully.

I don't know why this is. From the command line, type link\file fails as expected.

[dolmen]

Related: #71492 ("os: on Windows, Chmod acts on symlinks rather than the symlink target").

[qmuntal]

Disclaimer: all this is not good documented, and some behaviors are surprising. I'm just explaining what I've experimented.

don't know why this is. From the command line, type link\file fails as expected.

I wouldn't say that it is expected to fail. CreateFileW allows to open link\file (probably because it doesn't validate intermediate directories), so programs can work on it as a normal file. For example, you can get its content with PowerShell running Get-Content -Path dir\file. So I would say that the bug is in the type command.

Directory symbolic links only differ from file symbolic links in that the former have the FILE_ATTRIBUTE_DIRECTORY attribute, but that's just a hint for the callers, nothing else (AFAIK). You can open a symbolic link passing the FILE_FLAG_OPEN_REPARSE_POINT to CreateFileW, and that will always succeed, regardless of whether the symbolic link type is not consistent. What's true is that CreateFileW fails to open file symbolic links targeting directories when FILE_FLAG_OPEN_REPARSE_POINT is not set, probably because it performs some sanity checks.

Going back to the original issue. This is what we should do if we want to be consistent with Windows (which we want):

• Root.Open("link") should fail (it currently succeeds) when link is a directory symbolic link to a file.
• Root.Open("link") should fail (it currently succeeds) when link is a file symbolic link to a directory.
• Root.Open("link\file") should succeed (that's already happening) when link is a file symbolic link to a directory.