| HN Mirror

> I’ve used a VMWare Fusion shared folder between a Mac host and Linux/Windows guests for several years with zero issues. Performance has generally been very good, basic permissions work (haven’t needed anything beyond rwx), and I gain the ability to pretty freely move between host and guest with ease.

Not for me! I did that and one day ran a Git command on the Linux side of a folder shared from the host.

It crashed Git!

This turned out to be reproducible. It was quietly corrupting my local Git repo too.

Turns out VMware Fusion shared folder has extremely bad incorrect caching in its Linux client, with no option to turn the caching off.

So I switched to using SMB and Samba to share a Linux guest folder with the Mac host. That mostly worked but for 9 months I found a random file would occasionally just disappear, without me noticing for a few days.

I kept losing data, about once a month at random. I thought there must be a subtle bug in my application's careful handling of those files. The concern delayed production deployment for 9 months. But no, when running on a proper Linux server my application code had been fine all along

It turned out to be the Mac SMB client had a an awful bug that caused it to very occasionally delete random files in busy directories. The files had no relation to files being operated on, except for being in the same folder and recently used. It wasn't an operation race, it was blatantly sending the wrong file id for an operation on a different file by another process in parallel. Debugging that was intense. For months I had no idea, and thought it was my fault I lost data about once a month. Eventually I managed to trigger the fault more reliably with an artificial load test, and then it took a solid day of tracing everything you can imagine to confirm the cause was the Mac SMB client sending an egregiously wrong command on rare occasions.

Because the shared folder random file deletions were so vexing, rare and distressing, I investigated all sorts of causes, and in the process found another. A sequence where Emacs (GUI Emacs on the Mac host) asks to confirm editing a file "locked" by another Emacs (not really, just due to stale state), where if I gave the wrong answer sequence and aborted at the wrong monent, and editor backups were configured a particular way, the file ended up removed unexpectedly. I figured: Jackpot! Found the cause of disappearing data due to a race in Emacs in rare circumstances. I thought I must have triggered that sequence a few times. So I fixed it in my Emacs with great relief.

Than a month later another file was missing and I realised there was a second cause of disappearing files. That turned out to be the crazy bug in the Mac SMB client.

I have shared folder solutions that seems reliable enough now, both for sharing host folders with the guest and guest folders wih the host. It involves NFS and duct tape with Samba to translate permissions, because Macos doesn't support NFSv4. And CIFS (SMB version 1, obsolete) because later SMB versions had some problem. It's not great. The permissions don't map well and I had to change the config last time I upgraded Macos version.

All because VMware Fusion shared folder had such poor cache coherency.

> I also have some little quality-of-life scripts on the Linux side for things like editing shared files in the Mac editor, opening shared folders in Finder, etc. These make it a fairly seamless experience to go back and forth between the two OSes.

I have little scripts like yours too. They're great! Being able to edit a file in the Linux guest using the Mac GUI version of Emacs is really helpful, as is being able to open a PDF or DOC or XLS that's stored in the Linux guest. That sort of thing is the motivation for sharing my Linux home folder with the Macos host.

Oh, I also use Emacs TRAMP in a way that's so seamless I forget I'm using it, When editing Linux guest files at the path where the Linux home folder is mounted.on thr host, Emacs is configured to do so transparently over SSH to the guest instead. It works so well I forget I'm using TRAMP, and this avoids weird file permission issues and potential bugs like those I've seen before when writing to the shared folder directly. It also means when I run a shell command or compile etc. from Emacs with a buffer open on a Linux file path, the command runs on the guest, which is perfect.