> It was written by the ever exceptional Fabrice Bellard.

I think it is rather by Johannes Schindelin [1].

[1] https://github.com/qemu/qemu/commit/de167e416fa3d6e4bbdcac90...

On the other hand, I don't think we've ever seen Fabrice Bellard and Johannes Schindelin in the same room together.

That is... compelling, I admit, as Bellard was known for his use of various pseudonyms (e.g. Gérard Lantau for FFmpeg). But I guess Schindelin now works for Microsoft while Bellard still works for Amarisoft [1], right?

[1] https://www.amarisoft.com/about-us/

But if you rearrange, remove, and then add some letters to Amerisoft it spells MicroSoft. The implication is clear.

And now you can even write the regex for it into FAT32

Huh? Where do you get the 'c'? Typo?

>and then add some letters

That seems like the perfect solution to the problem of newer Android devices losing USB mass storage support because the internal data filesystem is no longer FAT32 and they combined the partitions together into a Linux-format one. Unfortunately a quick Google suggests no one has tried to take that file/concept and implement it so the Android device could present a virtual USB drive using that with a directory on the "host", but I guess that just makes it an idea for anyone else who has some time and would like an interesting challenge...

I can imagine other interesting use cases. fat32 over the network, for example: so you can e.g. plug in a USB device into some legacy hardware, and when it does a directory read, the device lies to the host about what's inside, only retrieving the bytes over the air during a file read operation.

I think the hard part is that if the "disk" is mounted, the FAT would be in memory on Windows, so it's very hard to put in a file from "outside", because Windows will probably never re-read the FAT from the disk and will never see that file.

Why can't they keep a fat32 driver around and mount it like they always have?

The data partition used to be FAT32 and plugging the Android into USB with the mass storage option would unmount the partition and then the Android emulates a USB mass storage device to expose the block-level contents of the partition to the host computer. Note that this couldn't be done with the system partition, since the Android system itself is running on it; and even if it was unmountable, the filesystem would be a Linux one like ext3 or ext4, making it unreadable to a Windows host. In the newer versions, they combined the two partitions into one with a Linux filesystem, so there would no longer be a separate data partition to unmount from the Android and mount on the host.

The idea I'm proposing is to turn VVFAT or an equivalent idea into a kernel module that treats the data directory --- or indeed any --- directory on the Android, including the system one, as the "host" since it has a filesystem-application interface on one side that just uses the normal filesystem calls, and expose the virtual FAT filesystem over USB mass storage on the other side.

Without knowing how QEMU does it, I'm guessing writes onto the emulated fat32 partition inside QEMU get caught by their software, and QEMU talks to Windows and says "Hello Windows, I would like to store this data as a file in this directory.". The directory can probably be on an NTFS disk or even Samba mount?

If a phone is "mounted" as FAT32, the writes from Windows should be intercepted by the driver and it would create Linux filesystem calls to create/write files. If an Android app decides to write onto that partition, there needs to be a program running on the Windows side to tell Windows' filesystem driver "Hey I'm going to create this file". Otherwise Windows will never see that file.

(I'm just guessing here, maybe there is a function to re-read the FAT?)

Oh, I was thinking about this the wrong way -- I had read it as Android's ability to mount USB OTG mass storage devices plugged into the phone.

I agree with you, if the internal filesystem can't be mounted as a filesystem on most PCs then there should be some sort of virtual/emulation layer.

The insane thing is supporting writes on the host side (are they?) which change the contents of the VFAT right under the guest OS. Writes in the other direction are a lot simpler because the guest is in control of the VFAT state.

Come on, any sort of caching scheme will wreak havoc with underhanded updates to the image.

I've used this feature quite a lot and it's important to understand that it is crazy unstable. The fact that it works at all is impressive, but it does explode quite a lot.

We discussed VVFAT at the KVM Forum (2018 IIRC), and as a response I wrote: http://libguestfs.org/nbdkit-floppy-plugin.1.html (It does not support all the crazy write/host filesystem interaction because I'm nowhere near as smart as Johannes Schindelin.)

I see another name as author and no trace of Fabrice in history. Can you elaborate please?

QEMU itself came from Bellard originally, but I believe you are correct that the RO and RW vvfat support came from Johannes Schindelin:

https://github.com/qemu/qemu/commit/de167e416fa3d6e4bbdcac90...

https://github.com/qemu/qemu/commit/a046433a161a1f554be55df8...