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

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

Closed
ericcornelissen opened this issue Nov 3, 2020 · 5 comments
Labels
FrozenDueToAge help wanted NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. OS-Windows
Milestone

Comments

@ericcornelissen
Copy link

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 ianlancetaylor added this to the Backlog milestone Nov 3, 2020
@ianlancetaylor ianlancetaylor added help wanted NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. OS-Windows labels Nov 3, 2020
@ianlancetaylor
Copy link
Contributor

CC @alexbrainman @mattn

@alexbrainman
Copy link
Member

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
Copy link
Member

mattn commented Nov 4, 2020

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
Copy link
Author

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
Copy link
Member

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

@golang golang locked and limited conversation to collaborators Nov 4, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
FrozenDueToAge help wanted 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

5 participants