The clever/insane thing is it supports writes. It is able to "reverse" those block level operations from the guest to modify the source filesystem on the host.

It was written by the ever exceptional Fabrice Bellard. EDIT: No it wasn't, it was written by Johannes Schindelin, thanks for the clarification in replies.

[1] https://github.com/qemu/qemu/blob/master/block/vvfat.c

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

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

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

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.

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.

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?)

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.

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

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

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

I saw the words, but my brain couldn't process them, no matter how many times I tried.

If I die of an aneurysm, regex2fat will probably be the reason why

It seems pretty straightforward to parse. I read it as:

  if(!somethingAboutMyHorse) {
    // ? Road not taken.
  } else {
    //Spend a year in college.
  }

There's an explanation on Reddit[1] which basically says that there's no logical explanation for why having a horse should have led to a year in college.

I was looking for some kind of grammatical trick, and judging by some of the replies here I'm not alone.

[1] https://www.reddit.com/r/OutOfTheLoop/comments/1twwao/why_is...

In one scene, he is sitting in a bar and an NPC sits next to him on a barstool and the dialog just spits out punchlines with no context.

"...and there stood the pig and the cow!"

English can be tricky that way.

> A: No, but I can't stop you.

The motto of so many of the best projects:)

https://github.com/8051Enthusiast/regex2fat/pull/2

> "A SFN filename can have at most 8 characters before the dot. If it has more than that, the first 6 must be written, then a tilde '~' as the seventh character and a number (usually 1) as the eighth. The number distinguishes it from other files with both the same first six letters and the same extension."

This is genius.

>A: Haha OS-driven regex engine go brrrrr

i absolutely love little toy things like this that probably shouldn't exist but do regardless, and even more so I love it when they close on a silly and playful note like this. this is a rather interesting concept and it reminds me a lot of the idea of glitterbombing from more occult/esoteric circles of the internet (performing acts of obscurity and aloof strangeness to degrade the meaning of consensual reality and expose people to a perspective of life they otherwise would not spend much time engaging in, sorta conceptually similar to Zen koans)

I thought it would be a cool idea to hack the filesystem to allow you to have directories of albums or genres or artists all cross-linking to the same music files.

I now see my "big dreams" were actually limited in scope.

I like that phrase as it sounds like “better” when we’re talking about, as you say, something wonderfully useless.

    /include/linux/namei.h:13    #define MAXSYMLINKS 40

https://docs.microsoft.com/en-us/windows/win32/fileio/naming...

I think you could make those files manually in a disk or sector editor just fine, and it might even show up in DIR, but of course accessing them via normal DOS usage would be hard if not impossible.

Regex though... this is humorous.

Like literally what does it do? I'm assuming there is a theoretical use case, even if as a toy project just for shits and giggles but I'm completely at a loss.

https://www.youtube.com/watch?v=tDUL3wEs2ew

You could also write a Samba VFS module that does the same thing with incoming filenames.

The file system could work around that by creating new unique directories whenever you write any file to an empty directory, but that would require it to keep the regular expression it represents around, and would fill up the file system quite rapidly.

Even automata based regex engines don't usually build up a full DFA, since the size of the DFA may be exponential in the size of the regex. Instead, an NFA similation might be used, or a hybrid NFA/DFA that builds the DFA during match time, but typically doesn't build out the full DFA.

https://perl.plover.com/Regex/article.html

Now someone build one that can compile new regexes in fat32.

haha regex engine go brrrrr