What version of Go are you using (go version)?
$ go version
go version go1.16.2 darwin/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
GO111MODULE=""
GOARCH="amd64"
GOBIN=""
GOCACHE="/Users/tigu/Library/Caches/go-build"
GOENV="/Users/tigu/Library/Application Support/go/env"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GOINSECURE=""
GOMODCACHE="/Users/tigu/go/pkg/mod"
GONOPROXY=""
GONOSUMDB=""
GOOS="darwin"
GOPATH="/Users/tigu/go"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/usr/local/opt/go/libexec"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/usr/local/opt/go/libexec/pkg/tool/darwin_amd64"
GOVCS=""
GOVERSION="go1.16.2"
GCCGO="gccgo"
AR="ar"
CC="clang"
CXX="clang++"
CGO_ENABLED="1"
GOMOD="/dev/null"
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -arch x86_64 -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/y4/d2xhlc550nv5wxfl3w1mr47xrjmbp2/T/go-build3207590417=/tmp/go-build -gno-record-gcc-switches -fno-common"
What did you do?
https://play.golang.org/p/u56BwqIWsKq
In short: calling fs.ReadDir on a *zip.Reader.
What did you expect to see?
ReadDir should only return a single entry under a/, since there is only a single directory under it.
What did you see instead?
a/b/
a/
a/b/c
=======
b
b
archive/zip's FS implementation seems to have treated a/b/ and a/b/c as two separate entries of the a/ directory, causing this behavior. Of course, one can work around this by creating a map of seen paths, but that just seems like extra hassle for something well-understood.
As a bonus, calling fs.WalkDir on a zip.Reader provides even more unexpected results (https://play.golang.org/p/spyKcwKc5TM):
a/b/
a/
a/b/c
=======
b
b
=======
.
a
a/b
a/b/c
a/b
a/b/c
a
a/b
a/b/c
a/b
a/b/c
What version of Go are you using (
go version)?Does this issue reproduce with the latest release?
Yes
What operating system and processor architecture are you using (
go env)?go envOutputWhat did you do?
https://play.golang.org/p/u56BwqIWsKq
In short: calling fs.ReadDir on a *zip.Reader.
What did you expect to see?
ReadDir should only return a single entry under a/, since there is only a single directory under it.
What did you see instead?
archive/zip's FS implementation seems to have treated a/b/ and a/b/c as two separate entries of the a/ directory, causing this behavior. Of course, one can work around this by creating a map of seen paths, but that just seems like extra hassle for something well-understood.
As a bonus, calling fs.WalkDir on a zip.Reader provides even more unexpected results (https://play.golang.org/p/spyKcwKc5TM):