PDB synchronous write errors even with /FS

Question

I have a simple CMakeLists to compile detours express

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)

The necessary flags are set in an upper level CMakeLists

add_definitions(-DDETOURS_X86 -DDETOURS_32BIT)
SET(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} /FS")
SET(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} /FS")

Yet when trying to compile a debug build each .cpp file after detours.cpp throws

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

If I re-run ninja detours then the same happens with the next 3 cpp files, then the next 2, then the last, then the project is fully compiled.

If I run ninja -j1 detours then there are no issues, since I just disabled parrallel builds.

Why does it seem to be ignoring my /FS option? I'm using Visual Studio 2013.

Update 1

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.

Update 2

I found a workaround that avoids the symptoms and added it as an answer, but it still doesn't explain why /FS isn't actually synchronizing the locks.

Answer 1

Not so much a solution as a workaround. It appears that whatever mechanism VirtualBox uses to implement shared folders is the culprit. I replaced the virtual box shared folder with a windows shared folder and I am no longer getting these errors.

It's strange that sequential builds don't cause these errors, perhaps compiling the first file causes a sync that prevents the other files from locking until it's done, and since the build is parallel the other .cpp files run into the lock. I'm not sure if this is VirtualBox's or MSVC's fault, though, since this seems like the kind of problem that /FS is supposed to fix.

Steps

1. Disconnect network map from within VM
2. Remove shared folder from VirtualBox settings
3. Setup a Windows Share on host (Right click folder -> Share)
4. Map this share in the VM