VirtioFS filesystem read+write mounts, "corrupted" state, unreliable synchronization (especially with git repositories)

[danielweck]

I have been a Tart user for some time (since before the OpenAi acquisition) but only for local VM isolation / "containerization" of workspaces. In other words I haven't used Tart for headless CI, instead I use Tart to safely develop software inside ephemeral sanboxed MacOS images.

When I started using Tart I immediately experienced significant issues with VirtioFS, especially with read+write filesystem mounts. Typically, modifying files in the host would reliably cause "corruption" issues in the guest OS (I would see weird characters in the console when cat-ing or git diff-ing files). This became a total deal-breaker with Git repositories shared from the host to the guest.

My current workaround is to git shallow-clone repositories from the host to the guest, so that filesystem-intensive operations are contained purely within the guest. This in turn means I have to manually synchronise the guest state with the host, which is cumbersome even with semi-automated scripts (I am planning on migrating to rsync to see if it helps reduce UX friction).

What puzzles me is that I thought VirtioFS was used in Docker Desktop, OrbStack, Apple Container etc. ... where I don't experience any issues whatsoever.

FYI this is also being discussed in GhostVM:

groundwater/GhostVM#255 (comment)

[Nicholas-Westby]

This happens to me several times a day. I have to point my agents to this workaround script so they can fix it temporarily: https://github.com/ai-sorcery/ai-sorcery/blob/main/plugins/sorcery/claude-vm/fix-cache.sh

And I've now been conditioned to not touch the files on the host side for fear that I'll make this happen and interrupt my work. It's a huge challenge to work with.

[danielweck]

Thanks for sharing! I'm glad it's not just me :)

[danielweck]

I've just read your "fix cache" shell script.

A full umount + mount cycle for the share is the only known fix short of rebooting the VM

yep, that's what I used to do, but it was very disruptive in my workflow because the unmount-remount dance required exiting my Flox(Nix) subshell, move out of the folder ... and inversely to get back to work.

What's sad is that all I needed to do from the host was git commit + push code sprints achieved in the guest, but even that simple .git/ filesystem operation on the host would cause the guest mount to go whacky out of sync and essentially enter a corrupted state.

[danielweck]

Probably related:

insidegui/VirtualBuddy#420