-
Notifications
You must be signed in to change notification settings - Fork 17.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
path/filepath: EvalSymlinks fails on Windows when passed a UNC share root path #42079
Comments
It looks like this can be fixed by just changing the line here to also have a case for However, I'm currently getting an error when trying to run tests in
|
Fixes golang#42079 Previously, EvalSymlinks returned an error when called with the root of a UNC share (e.g. \\server\share). This was due to Windows's FindFirstFile function not supporting a share root path. To resolve this, now return early from toNorm in the case where the path after the volume name is empty. Skipping the later path component resolution shouldn't have any negative impact in this case, as if the path is empty, there aren't any path components to resolve anyways. Signed-off-by: Kevin Parsons <[email protected]>
Fixes golang#42079 Previously, EvalSymlinks returned an error when called with the root of a UNC share (e.g. \\server\share). This was due to Windows's FindFirstFile function not supporting a share root path. To resolve this, now return early from toNorm in the case where the path after the volume name is empty. Skipping the later path component resolution shouldn't have any negative impact in this case, as if the path is empty, there aren't any path components to resolve anyways.
Fixes golang#42079 Previously, EvalSymlinks returned an error when called with the root of a UNC share (e.g. \\server\share). This was due to Windows's FindFirstFile function not supporting a share root path. To resolve this, now return early from toNorm in the case where the path after the volume name is empty. Skipping the later path component resolution shouldn't have any negative impact in this case, as if the path is empty, there aren't any path components to resolve anyways. The test case uses the localhost admin share (c$), as it should be present in most situations. This allows testing without setting up an external file share. However, this fix applies to all UNC share root paths.
Change https://golang.org/cl/263917 mentions this issue: |
I got the tests to work, and have a fix PR out now. |
What version of Go are you using (
go version
)?Does this issue reproduce with the latest release?
Yes
What operating system and processor architecture are you using (
go env
)?go env
OutputWhat did you do?
main.go
Repro:
What did you expect to see?
What did you see instead?
Details
This is due to
EvalSymlinks
using the Windows API FindFirstFile to attempt to resolve each path component after the volume name. Since\\localhost\c$
is parsed as the volume name with an empty path following it, this results in a call toFindFirstFile
for the path of\\localhost\c$
, which fails withThe system cannot find the file specified.
.The failure from
FindFirstFile
is expected. Per the documentation for that function:One important occurrence of this bug is with Kubernetes. The containerd/containerd runtime uses
EvalSymlinks
to resolve each container mount path on the host. When a mount path is the root of a UNC share (or a symlink to the share root), thenEvalSymlinks
fails, preventing the container from starting. More discussion on this in kubernetes/kubernetes#94213.As a workaround, if the path to
EvalSymlinks
has a\
appended, the function works properly, as it hits a conditional that causes an early return, before callingFindFirstFile
. However, it would be good to fix the source of this issue as well.Note: This repros for all UNC share roots passed to
EvalSymlinks
. I used the admin share (\\localhost\c$
) in the example, as that allows a repro without needing access to an external network share, which makes testing easier.The text was updated successfully, but these errors were encountered: