bazel: Modifications to bazel-[workspace] files do not invalidate bazel caches on Windows

Bazel version 0.5.2 on Windows 10.

If you modify a file under the symlinked bazel-[workspace] execroot path the bazel file watcher will not detect the changes. This can lead to very confusing runtime bugs as builds will succeed but be using partially complete object files that will still link but produce incorrect results.

The scenario where I hit this frequently is when modifying files from the Visual Studio debugger, which due to the way bazel passes sources to cl.exe resolves files to the symlinked workspace output paths instead of their original paths. If the original file is c:\my_workspace\source.h the pdb will reference the file as C:\Users\Ben\AppData\Local\Temp\_bazel_Ben\4qe-y0H3\execroot\my_workspace\source.h. The debugger will then open that file for display and allow me to modify it. If I do, bazel will not detect me changing the file (as it’s just a copy of the original file). If I then change a file bazel does track (such as c:\my_workspace\source.cc) bazel will recompile but not recopy the source.h file, resulting in a build that contains some objects with the old c:\my_workspace\source.h and new objects with the modified one under the execroot. Only sadness ensues and a bazel clean is required to get the state right again.

The fast fix to at least prevent this corruption would be to mark all files copied to the execroot as readonly (I believe that bazel does this on some platforms? I recall seeing read-only files on linux internally at some point). This would prevent accidental modification of the files that bazel is not tracking. The ideal fix (for developer workflows) would be either a way to have the pdbs reference the original files such that the debugger would open those or for bazel to also check on startup/watch for modification file times/etc in its execroot.