title: PDB synchronous write errors even with /FS
body: <p>I have a simple CMakeLists to compile detours express</p>
  
  <pre><code>project(detours)
  add_library(detours STATIC detours.cpp disasm.cpp image.cpp modules.cpp creatwth.cpp)
  file(COPY detours.h detver.h DESTINATION ${CMAKE_BINARY_DIR}/include)
  </code></pre>
  
  <p>The necessary flags are set in an upper level CMakeLists</p>
  
  <pre><code>add_definitions(-DDETOURS_X86 -DDETOURS_32BIT)
  SET(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} /FS")
  SET(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} /FS")
  </code></pre>
  
  <p>Yet when trying to compile a debug build each .cpp file after <code>detours.cpp</code> throws</p>
  
  <blockquote>
    <p>FAILED: C:\PROGRA~2\MICROS~1.0\VC\bin\cl.exe /nologo /TP -DDETOURS_32BIT -DDETOURS_X86 -Iinclude /DWIN32 /D_WINDOWS /W3 /GR /EHsc /FS /D_DEBUG /MDd /Zi /Ob0 /Od /RTC1 /showIncludes /Foext\detours_express_3.0\src\CMakeFiles\detours.dir\modules.cpp.obj \Fdext\detours_express_3.0\src\CMakeFiles\detours.dir\ /FS -c ..\ext\detours_express_3.0\src\modules.cpp
    ..\ext\detours_express_3.0\src\modules.cpp : fatal error C1041: cannot open program database 'z:\repo\src\ext\detours_express_3.0\src\cmakefiles\detours.dir\vc120.pdb'; if multiple CL.EXE write to the same .PDB file, please use /FS</p>
  </blockquote>
  
  <p>If I re-run <code>ninja detours</code> then the same happens with the next 3 cpp files, then the next 2, then the last, then the project is fully compiled.</p>
  
  <p>If I run <code>ninja -j1 detours</code> then there are no issues, since I just disabled parrallel builds.</p>
  
  <p>Why does it seem to be ignoring my /FS option?
  I'm using Visual Studio 2013.</p>
  
  <p><strong>Update 1</strong></p>
  
  <p>This is inside a VM in Virtualbox 4.3.10 with Guest Additions. Z:\ is a shared folder that I mounted.
  I've made sure to disable Windows Defender in the VM and the host, and uninstalled the third-party AV on the host.</p>
  
  <p><strong>Update 2</strong></p>
  
  <p>I found a workaround that avoids the symptoms and added it as an answer, but it still doesn't explain why <code>/FS</code> isn't actually synchronizing the locks.</p>