path/filepath: filepath.Abs("[...]\\...") returns different results on Windows than other systems

[ericcornelissen]

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

$ go version
go version go1.15.3 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\erico\AppData\Local\go-build
set GOENV=C:\Users\erico\AppData\Roaming\go\env
set GOEXE=.exe
set GOFLAGS=
set GOHOSTARCH=amd64
set GOHOSTOS=windows
set GOINSECURE=
set GOMODCACHE=C:\Users\erico\go\pkg\mod
set GONOPROXY=
set GONOSUMDB=
set GOOS=windows
set GOPATH=C:\Users\erico\go
set GOPRIVATE=
set GOPROXY=https://proxy.golang.org,direct
set GOROOT=D:\Program Files\Go
set GOSUMDB=sum.golang.org
set GOTMPDIR=
set GOTOOLDIR=D:\Program Files\Go\pkg\tool\windows_amd64
set GCCGO=gccgo
set AR=ar
set CC=gcc
set CXX=g++
set CGO_ENABLED=1
set GOMOD=
set CGO_CFLAGS=-g -O2
set CGO_CPPFLAGS=
set CGO_CXXFLAGS=-g -O2
set CGO_FFLAGS=-g -O2
set CGO_LDFLAGS=-g -O2
set PKG_CONFIG=pkg-config
set GOGCCFLAGS=-m64 -mthreads -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=C:\Users\erico\AppData\Local\Temp\go-build382298702=/tmp/go-build -gno-record-gcc-switches

What did you do?

package main

import (
	"fmt"
	"path/filepath"
)

func main() {
	fmt.Println(filepath.Abs("c:\\windows\\..."))
}

Or a play.golang.org link

What did you expect to see?

I expect the output to be c:\windows\...

What did you see instead?

Instead I saw c:\windows

Additional details

Based on my own quick investigation the problem seems to come from the syscall.FullPath() call, but within that function I wasn't able to determine why this is or how to fix it.

[ianlancetaylor]

CC @alexbrainman @mattn

[alexbrainman]

I expect the output to be c:\windows\...

Why?

This is how my command prompt works

C:\Users\Alex>cd c:\windows\...

c:\Windows>

I don't see why filepath should work differently. ... is, probably, valid file name, but you will have trouble using it from many Windows programs. Just don't use it.

Alex

[mattn]

I don't make sure but ... seems to be a special file. (but it is a legal filename)

https://devblogs.microsoft.com/oldnewthing/20160202-00/?p=92953

[ericcornelissen]

Why?

I should have been more specific. The reason I'm expecting that is because that "is" what I'm getting on my Linux machine (see go version and go env details below). Namely,

package main

import (
	"fmt"
	"path/filepath"
)

func main() {
	fmt.Println(filepath.Abs("./Documents/..."))
}

will output /home/Documents/... (assuming you're un ~) and not /home/Documents. Whereas running cd ./Documents/... outputs an error.

I'm not sure which approach is correct, i.e. whether "..." should be maintained by filepath.Abs or not, but I would expect the same behaviour between Windows and Linux (and Mac, but I cannot test that).

... is, probably, valid file name, but you will have trouble using it from many Windows programs. Just don't use it.

Just to clarify, I'm trying to use the ... notation to indicate "all files in this folder and any folder below", the same way as, e.g., go fmt ./... does, not as a file.

I don't make sure but ... seems to be a special file. (but it is a legal filename)

https://devblogs.microsoft.com/oldnewthing/20160202-00/?p=92953

I suppose that may explain why the behaviour is different between Windows and Unix 🤔

---

$ go version
go version go1.15.3 linux/amd64

go env Output

$ go env
GO111MODULE=""
GOARCH="amd64"
GOBIN=""
GOCACHE="/home/eric/.cache/go-build"
GOENV="/home/eric/.config/go/env"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOINSECURE=""
GOMODCACHE="/home/eric/.gvm/pkgsets/go1.15.3/global/pkg/mod"
GONOPROXY=""
GONOSUMDB=""
GOOS="linux"
GOPATH="/home/eric/.gvm/pkgsets/go1.15.3/global"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/home/eric/.gvm/gos/go1.15.3"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/home/eric/.gvm/gos/go1.15.3/pkg/tool/linux_amd64"
GCCGO="gccgo"
AR="ar"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
GOMOD=""
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build316514940=/tmp/go-build -gno-record-gcc-switches"

[alexbrainman]

The reason I'm expecting that is because that "is" what I'm getting on my Linux machine

I cannot expect Linux and Windows to behave the same. See #42362 (comment) Also nul file will work fine on Linux, but will do magic things on Windows. Same with /dev/null - it will work fine on Windows, but will behave strangely on Linux.

Just to clarify, I'm trying to use the ... notation to indicate "all files in this folder and any folder below", the same way as, e.g., go fmt ./... does, not as a file

... is only understood by Go command. It is magic thing that Go command supports. This magic can be implemented in any program by using existing tools and libraries.

Alex