Repository navigation
gomodfs: declare the WinFsp volume case-sensitive and case-preserving - #31
Merged
Merged
Conversation
gomodfs's paths are case-sensitive, like the GOMODCACHE layout it emulates (which escapes capital letters as "!x"), but the WinFsp mount claimed to be case-insensitive and not case-preserving. So for opens relative to a working directory on the mount, Windows passed gomodfs the working directory's path upcased, e.g. "TSGO-WINDOWS-AMD64/<HASH>/SRC/INTERNAL/ABI/textflag.h". gomodfs didn't recognize those paths and answered with an empty directory for any of them, so relative opens of files that don't exist succeeded and relative opens of files that do returned a directory. This broke Go builds using a Tailscale Go toolchain served from the mount: cmd/asm runs in each package's source directory and first tries to open #include files relative to it, so it "found" textflag.h there and then failed reading it with "The parameter is incorrect". Mount with winfsp.CaseSensitive(true) and FspFSAttributeCasePreservedNames so Windows passes names through verbatim. Add a CI test, run in the WinFsp job, that reads a file in the mounted module cache by a relative path; it fails before this change and passes after. Updates tailscale/corp#24037 Signed-off-by: Brad Fitzpatrick <bradfitz@tailscale.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
gomodfs's paths are case-sensitive, like the GOMODCACHE layout it
emulates (which escapes capital letters as "!x"), but the WinFsp mount
claimed to be case-insensitive and not case-preserving. So for opens
relative to a working directory on the mount, Windows passed gomodfs
the working directory's path upcased, e.g.
"TSGO-WINDOWS-AMD64//SRC/INTERNAL/ABI/textflag.h". gomodfs
didn't recognize those paths and answered with an empty directory for
any of them, so relative opens of files that don't exist succeeded
and relative opens of files that do returned a directory.
This broke Go builds using a Tailscale Go toolchain served from the
mount: cmd/asm runs in each package's source directory and first tries
to open #include files relative to it, so it "found" textflag.h there
and then failed reading it with "The parameter is incorrect".
Mount with winfsp.CaseSensitive(true) and
FspFSAttributeCasePreservedNames so Windows passes names through
verbatim. Add a CI test, run in the WinFsp job, that reads a file in
the mounted module cache by a relative path; it fails before this
change and passes after.
Updates tailscale/corp#24037