What version of Go are you using (go version)?

$ go version
go version go1.20.7 windows/amd64

Does this issue reproduce with the latest release?

Yes

What operating system and processor architecture are you using (go env)?

go env Output
$ go env
set GO111MODULE=
set GOARCH=amd64
set GOBIN=
set GOCACHE=C:\Users\qmuntaldiaz\AppData\Local\go-build
set GOENV=C:\Users\qmuntaldiaz\AppData\Roaming\go\env
set GOEXE=.exe
set GOEXPERIMENT=
set GOFLAGS=
set GOHOSTARCH=amd64
set GOHOSTOS=windows
set GOINSECURE=
set GOMODCACHE=C:\Users\qmuntaldiaz\go\pkg\mod
set GONOPROXY=
set GONOSUMDB=
set GOOS=windows
set GOPATH=C:\Users\qmuntaldiaz\go
set GOPRIVATE=
set GOPROXY=https://proxy.golang.org,direct
set GOROOT=C:\Users\qmuntaldiaz\sdk\go1.20.7
set GOSUMDB=sum.golang.org
set GOTMPDIR=
set GOTOOLDIR=C:\Users\qmuntaldiaz\sdk\go1.20.7\pkg\tool\windows_amd64
set GOVCS=
set GOVERSION=go1.20.7
set GCCGO=gccgo
set GOAMD64=v1
set AR=ar
set CC=gcc
set CXX=g++
set CGO_ENABLED=1
set GOMOD=C:\Users\qmuntaldiaz\code\gotest\go.mod
set GOWORK=
set CGO_CFLAGS=-O2 -g
set CGO_CPPFLAGS=
set CGO_CXXFLAGS=-O2 -g
set CGO_FFLAGS=-O2 -g
set CGO_LDFLAGS=-O2 -g
set PKG_CONFIG=pkg-config
set GOGCCFLAGS=-m64 -mthreads -Wl,--no-gc-sections -fmessage-length=0 -fdebug-prefix-map=C:\Users\QMUNTA~1\AppData\Local\Temp\go-build3933964541=/tmp/go-build -gno-record-gcc-switches

What did you do?

package main

import "os"

func main() {
    fi1, err := os.Stat(`\\.\pipe\`)
    if err != nil {
        panic(err)
    }
    fi2, err := os.Stat("NUL")
    if err != nil {
        panic(err)
    }
    if os.SameFile(fi1, fi2) {
        panic(`os.SameFile(fi, fi2) = true`)
    }
}

What did you expect to see?

os.SameFile does not report \.\pipe\ and NUL as the same file

What did you see instead?

os.SameFile reports \.\pipe\ and NUL as the same file

@golang/windows

Comment From: qmuntal

The root cause is the following: even if the file system supports file IDs, there are some files which, for whatever reason, don't have one assigned. MS-FSCC 2.1.7 specify how to handle this cases:

For file systems that do not support a 64-bit file ID, this field MUST be set to 0, and MUST be ignored.

For files for which a unique 64-bit file ID cannot be established, this field MUST be set to 0xffffffffffffffff, and MUST be ignored.

os.SameFile is not following this part of the spec. As \.\pipe\ and NUL file ID is 0, then it things they both are the same file.

Fixing this is not as straightforward as it seems, because we still want, for example, that os.SameFile("NUL", "NUL") returns true. I'm afraid a foolproof solution doesn't exist, as we have to fallback to comparing paths, which can led to false negatives in the presence of hard links. This is the best guidance I could find: https://devblogs.microsoft.com/oldnewthing/20220128-00/?p=106201.

If the volume doesn’t support 64-bit identifiers either, then the situation is getting kind of desperate. My colleague Malcolm Smith suggests calling Get­Final­Path­Name­By­Handle with FILE_NAME_NORMALIZED to try to get the file names into some sort of sane state, and then comparing the names.

Comment From: gopherbot

Change https://go.dev/cl/543815 mentions this issue: os: fix SameFile()

Comment From: gopherbot

Change https://go.dev/cl/543835 mentions this issue: os: fix SameFile()

Comment From: gopherbot

Change https://go.dev/cl/574155 mentions this issue: os: make readdir more robust on Windows