While implementing WCOW for the containerd snapshotter (containerd/containerd#4419), I bounced off golang/go#26033 in calls to fstest.CheckDirectoryEqualWithApplier and had to work around it rather nastily.

The summary of the issue is that filepath.Walk does not walk through Volume Mount Points (i.e. how a WCOW Layer is mounted to the local filesystem), because Go see it as a symlink, rather than a mount-point (bind, overlay, etc) as you would see on Unix systems for the same behaviour.

There are four approaches I can see to fixing this:

1. Hoping Go changes behaviour for mount-points where that mount-point is the "canonical DOS name", i.e. like a non-bind mount, and hence resolves path/filepath: filepath.Walk does not work on mounted volumes in Windows containers golang/go#26033. (And for bind-mount-style mounts, but I assume at some point they chose the current approach of treating Windows bind-mounts as symlinks).
2. Keeping the current changes in the containerd tests from my PR, and hoping it passes code-review.
3. Implement a Window-specific PathDriver in containerd's test helpers, which overrides Walk, and either directly recognises volume mounts, or points to a newly-overridden Stat in a Driver, with the latter reporting a volume mount point as a directory, not a symlink.
4. Same thing, but in continuity as the default on Windows.
5. A hybrid: pathDriver in continuity has Walk changed to always call Driver.Lstat, and containerd's test framework can provide a modified Driver.Lstat.

This ticket is to ask whether that fourth or fifth options seems reasonable, before I come to creating PRs towards improving this situation; or take option 2 and just work around it.