Windows reparse point handling has changed, we need to check it out:

=== RUN   TestWalkTraverseDirJunct
    walkfs_test.go:85: Directory junction was not traversed
--- FAIL: TestWalkTraverseDirJunct (0.03s)
=== RUN   TestWalkInfiniteRecursion
    walkfs_test.go:132: Infinite recursion not detected correctly
--- FAIL: TestWalkInfiniteRecursion (0.04s)

Possibly, as simple as just removing our reparse handling entirely for 1.23+, my reading is that mount points are now just followed and don't look like symlinks any more.

On Windows, the mode bits reported by Lstat and Stat for reparse points changed. Mount points no longer have ModeSymlink set, and reparse points that are not symlinks, Unix sockets, or dedup files now always have ModeIrregular set.

@calmh On a Windows 11 Pro amd64 box (10.0.22631.4037), the tests pass:

>go version
go version go1.23.0 windows/amd64
>go test -v -run TestWalk
=== RUN   TestWalkTraverseDirJunct
--- PASS: TestWalkTraverseDirJunct (0.02s)
=== RUN   TestWalkInfiniteRecursion
--- PASS: TestWalkInfiniteRecursion (0.03s)
PASS
ok      github.com/syncthing/syncthing/lib/fs   0.820s

So perhaps these issues are specific to Windows Server 2022 10.0.20348?

I spun up a Windows 10 Pro amd64 VM (10.0.19045.2965), and the errors appeared. I'll try a Windows 11 VM now...

The tests pass on a Windows 11 VM Pro amd64 23H2 10.0.22631.2861.

Well that's worrying.

I committed a change that fixed the test failures on my Windows 10 VM. I haven't tested the change otherwise.

I don't like that fix. For one, if the symlink bit isn't set (which is indeed a documented change in Go 1.23), we shouldn't need to do the reparse handling, we should already traverse the directory as is. Additionally, this would mean we try to parse reparse points on every Lstat which would likely be a significant performance regression.

@rasa can you break it down to a minimal reproducer? IMHO this is a go bug.

@calmh Yes, I will replace that change with a proper one.

It appears we can replace all or most of our readReparseTag, with using Stat().ReparseTag instead, which was introduced in go1.11, as Reserved0, then renamed to ReparseTag in go1.21rc1, but not mentioned in the release notes.

I've assigned this to myself, and will test the code on both my VMs, as well as GitHub's windows-2022 and windows-2019 instances.

@bt90 I guess your right that it's a go bug. Go should return consistent results regardless of what version of Windows its run on.

A solution is forthcoming. Here's a preview:

// There are cases where files are tagged as symlink, but they end up being
// something else. Make sure we properly handle those types.
if err == nil {
	if f.junctionsAsDirs {
		var checkIfJunction bool
		// godebug("winsymlink") will return >0 if GODEBUG=winsymlink=0 is set
		if compare.Compare(runtime.Version(), "go1.23") >= 0 && godebug("winsymlink") == 0 {
			checkIfJunction = fi.Mode()&os.ModeIrregular != 0
		} else {
			checkIfJunction = fi.Mode()&os.ModeSymlink != 0
		}

		// NTFS directory junctions can be treated as ordinary directories,
		// see https://forum.syncthing.net/t/option-to-follow-directory-junctions-symbolic-links/14750
		if checkIfJunction {
			if reparseTag, reparseErr := readReparseTag(name); reparseErr == nil && isDirectoryJunction(reparseTag) {
				return &dirJunctFileInfo{fi}, nil
			}
		}
	}

	// Workaround for #9120 till golang properly handles deduplicated files by
	// considering them regular files.
	if fi.Mode()&os.ModeIrregular != 0 {
		if reparseTag, reparseErr := readReparseTag(name); reparseErr == nil && isDeduplicatedFile(reparseTag) {
			return &dedupFileInfo{fi}, nil
		}
	}
}

return fi, err

// Create a sample for the metric.
sample := make([]metrics.Sample, 1)
sample[0].Name = myMetric

// Sample the metric.
metrics.Read(sample)

// Check if the metric is actually supported.
// If it's not, the resulting value will always have
// kind KindBad.
if sample[0].Value.Kind() == metrics.KindBad {
	return 0
}
// Handle the result.
// It's OK to assume a particular Kind for a metric;
// they're guaranteed not to change.
return sample[0].Value.Uint64()

The below code works in go1.21, go1.22, and go1.23, on windows 10, 11, windows-latest (windows-2022) and windoes-2019, with or without GODEBUG=winsymlink=0 set:

func (f *BasicFilesystem) underlyingLstat(name string) (os.FileInfo, error) {
	fi, err := os.Lstat(name)

	if err == nil && f.junctionsAsDirs {
		v := reflect.Indirect(reflect.ValueOf(fi))
		y := v.FieldByName("ReparseTag")
		if y.Interface() == uint32(windows.IO_REPARSE_TAG_MOUNT_POINT) {
			return &dirJunctFileInfo{fi}, nil
		}
	}

	return fi, err
}

Is it acceptable to use reflect to access non-public members of a FileInfo? It sure makes things faster and simpler.

Another solution that would work for at least two years would be to add

//go:debug winsymlink=0

to the existing file. This would force the pre-go1.23 functionality.

I would prefer we understand what's going on and do the minimal fix. We shouldn't need to change our reparse parsing stuff, only when to trigger it. In principle it seems to me this should be just adding a "if go1.22" to our existing symlink-to-reparse-point check and in go1.23+ do nothing at all as it should just look like a normal directory.