go: os: IsDir doesn't work with Windows OneDrive

I think there is an issue with FileInfo.IsDir in Windows 10 using the new Files On-Demand feature of OneDrive. (This occurs only after the Fall Creator Update that introduce this feature).

If I create a folder in OneDrive (with the Files-On-Demand feature on) IsDir return false. Note that just after the creation it return true but once OneDrive finish its sync it then return false. Also if I deactivate the Files-On-Demand feature I no longer repro (for newly created folder, the old one still have the issue). Using the “Always keep on the device option” or the “Free up space” doesn’t change the repro.

Also I may miss something obvious, I never used Go before but I found this issue while debugging and issue with Hugo (a site generator in Go).

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

go version go1.9.2 windows/amd64

Does this issue reproduce with the latest release?

Yes

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

set GOARCH=amd64
set GOBIN=
set GOEXE=.exe
set GOHOSTARCH=amd64
set GOHOSTOS=windows
set GOOS=windows
set GOPATH=C:\Users\theo\go
set GORACE=
set GOROOT=C:\Go
set GOTOOLDIR=C:\Go\pkg\tool\windows_amd64
set GCCGO=gccgo
set CC=gcc
set GOGCCFLAGS=-m64 -mthreads -fmessage-length=0
set CXX=g++
set CGO_ENABLED=1
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

My OneDrive version is: Version 2017 (Build 17.3.7105.1024)

What did you do?

package main

import (
	"fmt"
	"os"
)

func main() {
	src := "C:\\Users\\theo\\folder"
	srcO := "C:\\Users\\theo\\OneDrive\\folder"
	fi, err := os.Stat(src)
	fmt.Println(fi.IsDir())
	fmt.Println(err)

	fiO, errO := os.Stat(srcO)
	fmt.Println(fiO.IsDir())
	fmt.Println(errO)
}

What did you expect to see?

true
<nil>
true
<nil>

What did you see instead?

true
<nil>
**false**
<nil>

About this issue

  • Original URL
  • State: closed
  • Created 7 years ago
  • Reactions: 4
  • Comments: 43 (30 by maintainers)

Most upvoted comments

@kolyshkin I played with files on deduped volume. I am happy to report that, you are correct - all files on deduped volume looks like files now, because Windows reports then with both FILE_ATTRIBUTE_REPARSE_POINT and IO_REPARSE_TAG_DEDUP set. So after my CL 143578 - which only checks for FILE_ATTRIBUTE_REPARSE_POINT - they will be interpreted as symlinks. I suppose you are saying they should be plain files, not symlinks, and I cannot go ahead with CL 143578 unless I find way to check for IO_REPARSE_TAG*. Fair enough.

Alex

Interesting… If they are not true symlinks, then it would seem that would strengthen the case that the IO library should treat them as files transparently. Especially if there are guarantees that “cloud reparse points” will always behave just as files do (in the sense that they’re not going to cause loops while listing directory contents, etc.).