Symlinked runfiles on Windows don't work when longer than MAX_PATH

[JohanLaine]

Description of the problem / feature request:

Using symlink'd runfiles in tests on Windows is possible using the flag --experimental_enable_runfiles. However, if paths get too long (MAX_PATH, 260 characters), something breaks. I don't know if it "long" symlinks themselves are broken on Windows or if this is a Bazel bug. It is clear that this starts happening when the paths get longer than MAX_PATH.

Bugs: what's the simplest, easiest way to reproduce this bug? Please provide a minimal example if possible.

I have created a repository with a minimal example: https://github.com/JohanLaine/BazelFileLengthExample

On Windows, clone the repository, and run bazel test //… with Bazel 0.22.0 installed and set up as detailed in https://docs.bazel.build/versions/master/install-windows.html. The two first tests succeed but the third one fails. If you're unsure that it's really about file length, you can shorten one of the folder names in the failing test until it succeeds. Or alternatively, increase file lengths in a successful test until it fails.

What operating system are you running Bazel on?

Windows 10

What's the output of bazel info release?

INFO: Invocation ID: 5d00f4ab-428c-4691-8082-fbf810dcdf53
release 0.22.0

What's the output of git remote get-url origin ; git rev-parse master ; git rev-parse HEAD ?

https://github.com/JohanLaine/BazelFileLengthExample.git
b5fad4ab45888a18dc307d92a74516a47c31846a
b5fad4ab45888a18dc307d92a74516a47c31846a

Have you found anything relevant by searching the web?

cf791b5 definitely looks like a fix to this issue but from what I can tell, this fix is present in Bazel 0.22 and my example still fails.

Other than that, most of the behavior regarding symlinks and runfiles is documented in the Bazel documentation or in discussion documents like https://docs.google.com/document/d/1hnYmU1BmtCSJOUvvDAK745DSJQCapToJxb3THXYMrmQ/edit. No mention of what happens when the paths are "long" (longer than MAX_PATH) though.

Relevant related issue: #5807

[JohanLaine]

Pinging @meteorcloudy since you authored cf791b5 :)

[meteorcloudy]

Sounds like this is the same issue that's addressed at #7222, the fix is not in 0.22.0, but will be released in 0.23.0. Can you try with the release candidate of 0.23.0?

You can download it from:
https://releases.bazel.build/0.23.0/rc2/index.html

[meteorcloudy]

As pointed out in #7222, when opening a file at a long path with ifstream, you'll have to use an absolute Windows path with \\?\ prefix. eg. \\?\C:\foo\bar\...\file.txt.
So you probably also have to fix LongNameForFolderNumberOne/LongNameForFolderNumberTwo/LongNameForFolderNumberThree/reading_test.cpp to make the test pass.

[JohanLaine]

Thank you for the quick answer!

Changing to essentially "\\\\?\\" + getCwd() +" \\LongNameForFolderNumberOne\\....." works, and as it turns out it even works with Bazel versions as far back as 0.19! (I didn't try older than 0.19.1.) I'm sure I've tried prepending an absolute path with \?\ before but I must've made some other mistake at that point.

It is very unfortunate for us that we cannot write the relative path using / separator, we would naturally prefer our code to be both platform and build system agnostic. But if that is a limitation with ifstream itself when it comes to long paths on Windows, the issue isn't with Bazel. If you agree with me, you can close this issue.

[meteorcloudy]

@JohanLaine Totally agree!