Spurious errors when accessing host files thru shared folders

[fgrieu]

I encounter a spurious problem where some data read from files is corrupted when
- accessing many files from a window (7) x86-64 guest
- with the files in a folder of a windows (10) x86-64 host
- specifically, thru the Virtualbox Shared Folder (VSF) mechanism.

I'm compiling an embedded project. I don't get the same errors for two consecutive compilations of the same source file (which includes many headers). Often it works for a single file. From the nature of the unstable errors that I get from the compiler, it seems to most often manage to open the right files, but reach EOF too soon (there are a few file not found errors, but that's rare). The files themselves are OK, only the data read from them thru VSF is occasionally truncated (or perhaps otherwise wrong). The compiler and the IDE it runs in are 32-bit Windows exe/ddl residing on the client's boot disk. The misread header files are read thru VSF.

I have had the problem for years, in Virtualbox 6 and 7. It went from rare to systematic when I moved to a clang-based compiler on the client. Currently I'm using Virtualbox 7.0.12 on host, and guest additions 7.0.13-160164 to workaround for an unrelated issue (viewtopic.php?t=110597)

I have two reliable workarounds: to workaround a specific issue.
- Work on a copy of the folder (made thru VSF to the client's main disk); but this is inconvenient.
- or share the folder otherwise than by VSF. Specifically: enable file sharing on the Windows host, share the folder thru that on the host, and access the folder from the guest thru Windows's built-in file sharing and the emulated network connection to the host. However network configuration also allowing use of a physical emulator gets hairy, and against company policies.

Things I tried to no avail
- disable security software on host and client
- assign a drive letter to the shared folder in the client, or not
- allocate a single CPU to the client
- disable explicit parallel compilation in the client and compile file by file
- compute hashes of all the files, compare guest vs host: perfect match
- rebuild the client VM from scratch
- move to a different Windows 10 x86-64 host
- the hack recommended against "Long Delays When Accessing Shared Folders" in the Virtualbox 7.0.12 manual

I had not found a similar issue in the bugtracker. And it is hard to reproduce and diagnose, so I'm not keen to enter a report yet.

Things I'm ready to try
- rebuilding the client VM in Windows 10
- writing a program simulating what the compiler does and allowing a diagnostic
- moving to a Linux host
- any feasible suggestion.

TIA

[scottgus1]

Virtualbox Shared Folders was intended to be a drop-in alternative for real shared folders over a network. However, it hasn't always worked out that way.

Consider Virtualbox Shared Folders as good for file & folder copying only, when no direct network to the host is available (or when the VM is using NAT or NAT Network).

Use real shared folders provided by the host OS over a Bridged or Host-Only network for everything else a shared folder is expected to do. For your compiling situation, real shared folders or bust.

network configuration also allowing use of a physical emulator gets hairy, and against company policies.

If you need real shared folders to do your work, tell your bosses. They'll get IT to authorize the connection. FWIW Virtualbox is not an emulator. It generates a second "PC" on your desktop. It's like using two physical PCs.

[fgrieu]

Consider Virtualbox Shared Folders as good for file & folder copying only, when no direct network to the host is available (or when the VM is using NAT or NAT Network).

Use real shared folders provided by the host OS over a Bridged or Host-Only network for everything else a shared folder is expected to do. For your compiling situation, real shared folders or bust.

Thanks for the advice. My experience concurs.

The manual (7.0.10) states VSF "is similar to how you would use network shares in Windows networks, except that shared folders do not require networking, only the Guest Additions. Shared folders are supported with Windows 2000 or later", and the closest to documented limitations are:
- "For Windows guests, shared folders are implemented as a pseudo-network redirector" whatever that means.
- "The performance for accesses to shared folders from a Windows guest might be decreased due to delays during the resolution of the Oracle VM VirtualBox shared folders name service", with a workaround for that.

Thus my issue, if made reproducible and not in the tools I put on the client, would qualify as a bug, likely of the Windows Guest Additions. VSF is so convenient compared to my alternatives that I'm not quite ready to give it up.

[scottgus1]

The manual (7.0.10) states

Equivalent to:

Virtualbox Shared Folders was intended to be

So this:

would qualify as a bug

is probably accurate.

A Bugtracker ticket with reproducing steps and logs may help.

If work needs to get done, real shared folders or folder copying are the only known alternatives. We on the forum can't change the Guest Additions or host Virtualbox source code; there's not much we can do to make Virtualbox Shared Folders work better.

[fth0]

FWIW, if your guest OS is a 32-bit Windows 7, another user with a 32-bit Linux guest OS reported an (unsolved) issue last year that could somehow be related: shared folder problem! can see files but with wrong data!.

[fgrieu]

if your guest OS is a 32-bit Windows 7, another user with a 32-bit Linux guest OS reported an (unsolved) issue last year that could somehow be related: shared folder problem! can see files but with wrong data!.

Both my guest and host OSes are 64-bit Windows. The only 32-bit thing in my case is that the tools that experience the issue are 32-bit (I added details in the head post). There however are some similarities with the linked thread.