Description
In the documentation to filepath.Walk, it says "Walk does not follow symbolic links." This is not the case on Windows, and I think it's a bug.
What version of Go are you using (go version)?
$ go version
go version go1.7.1 windows/amd64
What operating system and processor architecture are you using (go env)?
$ go env
set GOARCH=amd64
set GOBIN=
set GOEXE=.exe
set GOHOSTARCH=amd64
set GOHOSTOS=windows
set GOOS=windows
set GOPATH=x:\go
set GORACE=
set GOROOT=C:\Go
set GOTOOLDIR=C:\Go\pkg\tool\windows_amd64
set CC=gcc
set GOGCCFLAGS=-m64 -mthreads -fmessage-length=0
set CXX=g++
set CGO_ENABLED=1What did you do?
Run the following program:
package main
import (
"fmt"
"io/ioutil"
"os"
"path/filepath"
)
func main() {
tempdir, err := ioutil.TempDir("", "")
if err != nil {
panic(err)
}
defer os.RemoveAll(tempdir)
err = os.Symlink(`c:\`, filepath.Join(tempdir, "directorysymlink"))
// err = os.Symlink("/", filepath.Join(tempdir, "directorysymlink"))
if err != nil {
panic(err)
}
err = filepath.Walk(tempdir, func(path string, info os.FileInfo, err error) error {
if err != nil {
return err
}
/*
if info.Mode()&os.ModeSymlink != 0 && info.Mode()&os.ModeDir != 0 {
return filepath.SkipDir
}
*/
fmt.Println(path)
return nil
})
if err != nil {
panic(err)
}
}What did you expect to see?
I expect filepath.Walk not to recurse into tmpdir/directorysymlink. So I expect to see:
C:\cygwin\tmp\337883043
C:\cygwin\tmp\337883043\directorysymlink
When run on a non-Windows system, this is the behaviour seen.
What did you see instead?
I see two problems.
- filepath.Walk recurses into tmpdir/directorysymlink (this issue).
- filepath.Walk hits an endless recursive loop due to path/filepath: Walk walks recursive NTFS junction points #10424. NB: This issue refers to NTFS junction points, whereas I am referring to directory symlinks.
C:\cygwin\tmp\902833999
C:\cygwin\tmp\902833999\directorysymlink
...
C:\cygwin\tmp\902833999\directorysymlink\Documents and Settings
C:\cygwin\tmp\902833999\directorysymlink\Documents and Settings\All Users
C:\cygwin\tmp\902833999\directorysymlink\Documents and Settings\All Users\Application Data
C:\cygwin\tmp\902833999\directorysymlink\Documents and Settings\All Users\Application Data\Application Data
C:\cygwin\tmp\902833999\directorysymlink\Documents and Settings\All Users\Application Data\Application Data\Application Data
C:\cygwin\tmp\902833999\directorysymlink\Documents and Settings\All Users\Application Data\Application Data\Application Data\Application Data
C:\cygwin\tmp\902833999\directorysymlink\Documents and Settings\All Users\Application Data\Application Data\Application Data\Application Data\Application Data
C:\cygwin\tmp\902833999\directorysymlink\Documents and Settings\All Users\Application Data\Application Data\Application Data\Application Data\Application Data\Application Data
C:\cygwin\tmp\902833999\directorysymlink\Documents and Settings\All Users\Application Data\Application Data\Application Data\Application Data\Application Data\Application Data\Application Data
C:\cygwin\tmp\902833999\directorysymlink\Documents and Settings\All Users\Application Data\Application Data\Application Data\Application Data\Application Data\Application Data\Application Data\Application Data
C:\cygwin\tmp\902833999\directorysymlink\Documents and Settings\All Users\Application Data\Application Data\Application Data\Application Data\Application Data\Application Data\Application Data\Application Data\Application Data
C:\cygwin\tmp\902833999\directorysymlink\Documents and Settings\All Users\Application Data\Application Data\Application Data\Application Data\Application Data\Application Data\Application Data\Application Data\Application Data\Application Data
panic: GetFileAttributesEx C:\cygwin\tmp\902833999\directorysymlink\Documents and Settings\All Users\Application Data\Application Data\Application Data\Application Data\Application Data\Application Data\Application Data\Application Data\Application Data\Application Data\Application Data: The system cannot find the path specified.
Final notes:
- a workaround for getting better behaviour is presented in the code above commented with /.../, but I don't think the library caller should be required to do this.
- I think Go should respect the underlying platform's (right or wrong!) decision to allow filesystem objects which report as both directory and symlink, and handle this appropriately in filepath.Walk by casting out directories which are also symlinks.
- FWIW, I think path/filepath: Walk walks recursive NTFS junction points #10424 is legitimate and filepath.Walk should also not follow directory junctions (hardlinks), so as to avoid recursive loops.