syscall: Go Build Fails on Windows With Long Paths

[cretz]

Opening by request in #3358

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

go version go1.8beta2 windows/amd64

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

Win64

What did you do?

Tried to compile several files, many with long names, in a folder via go build

What did you expect to see?

Successful compile

What did you see instead?

go build github.com/cretz/myproj: C:\dls\go1.8\go\pkg\tool\windows_amd64\compile.exe: fork/exec C:\dls\go1.8\go\pkg\tool\windows_amd64\compile.exe: The filename or extension is too long.

[bradfitz]

My guess is that problem is that the magic we added to the os package doesn't help the syscall package, since syscall (where the exec happens) doesn't use os.

Maybe we need to move the os package's support routines (building the UNC paths) into an internal support package usable by both os and syscall.

/cc @quentinmit

[bradfitz]

And /cc @alexbrainman

[cretz]

@bradfitz - I think this would be handled by the caller of Exec instead of in syscall directly since they are opaque strings and the difference between a file path and any other arbitrary string is determined by the caller. I do agree that this and the os package should share the same path-fixing code. I also agree it should be an internal function for now until more thought is given to expose (maybe os/exec.OSSafePath but it's really annoying to abstract a Windows -only issue).

[harshavardhana]

Why not have filepath.LongPath() function to be used for these situations?

[kardianos]

@harshavardhana If the go std lib handles windows long filepaths, which I think is great, I don't think it would be good to expose it anywhere except (maybe) in syscall, as this is a really platform specific issue where the fix doesn't need to affect API.

[bradfitz]

Yeah, no new public API.

[harshavardhana]

@harshavardhana If the go std lib handles windows long filepaths, which I think is great, I don't think it would be good to expose it anywhere except (maybe) in syscall, as this is a really platform specific issue where the fix doesn't need to affect API.

👍

[quentinmit]

We very consciously did not make syscall transparently handle long paths, because it would be confusing if the resulting syscall was called with different arguments than the caller intended.

Probably the right thing to do is to teach os/exec to use the same long path handling as os.

[bradfitz]

Actually, os/exec just uses os.StartProcess. So this is in the os package after all.

I'll send out a fix.

[gopherbot]

CL https://golang.org/cl/34725 mentions this issue.

[bradfitz]

Not trivial, it turns out. Somebody should tackle it during Go 1.9. https://golang.org/cl/34725 might be a good starting point. It has some debugging notes in it and a test.

[kardianos]

If I was to guess, the UNC meses with the quote logic; guess only.