Currently computers use the file system for computer storage, this isn't ideal for servers for a few reasons.

It's currently possible to include a virus sample in a computer to cause the server to show an antivirus warning that a virus has been downloaded. Although harmless as you can't run it, it can be annoying when people do this.

Additionally, from a security perspective it'd be nice to not have file system access as it can be a good gadget to run an attack. It's not on it's own exploitable, but can be used as a component of an attack.

An example attack would be a badly implemented mod trying to open a log file and an attacker is able to override the path, such as ./test.log/../MY_EVIL_PATH. On it's own this would be hard to exploit, since most people don't have a do-evil-things.bat file on their PC. However if the server was using CC, the attacker could store a .bat file on a computer and open it to run code. The vulnerability isn't within CC, but it's a gadget the attacker can us.

The current behaviour is really useful for developers and I would not want it removed, but it would be nice for servers to be able to use a simplified file system, maybe even just a JSON file, to avoid these issues.

If you want, you can make this change on a local scale via a datapack, using a script in /rom/autorun which replaces fs with an alternate implementation that stores data in a single file. It's a bit tedious to write, but there's various examples around the internet that you can start from.

Semi-related: my Phoenix operating system has a few filesystem modules which do a similar thing, including one that loads a filesystem from a serialized Lua table (no write-back though), and one that compresses every file written to disk (which would avoid malware flagging). If Phoenix was forced to boot from ROM using one of those modules, this would accomplish your goal (not saying you should though!).

Ah, if this can be done with adding a script to the autorun then I don't think it needs to be implemented in the core mod. If someone wants this behaviour they could just install a plugin or manually set it up.

If you want, you can make this change on a local scale via a datapack, using a script in /rom/autorun which replaces fs with an alternate implementation that stores data in a single file.

I'm not sure I'd want to rely on that. Lua-based sandboxing is tricky to get right — for instance, you need to guard against accessing the original function via the debug API, and I can't guarantee that there won't be other ways to obtain this in the future (for instance, I don't know if anything in #2097 is "exploitable").

Honestly, the quickest fix here is to not run a (public) Minecraft server on Windows. This definitely doesn't fix all issues¹, but does at least prevent the anti-virus warnings :p.

This would likely have major performance implications. If we assume each computer uses a single json file as its "filesystem", then there exists an issue with updating that data. Instead of just writing the thing that changed and being done with it, the computer would have to:

1. Either read in the current state or always keep the entire computer's filesystem in memory.
2. Alter the thing that needs to be altered.
3. Serialize the entire filesystem.
4. Write the entire filesystem.

A common pattern for turtle programming is to keep a small data file alongside the main file. This allows the turtle to 'recover' its position if it shuts down (server shutdown, chunk unload, etc). Before and after every movement, it will write a very small amount of data to the disk. With this change, that small fs change after each and every movement is now going to generate huge file writes (and potentially reads), as the entire state of the filesystem must now be re-serialized and re-written.

Large programs like LevelOS (which I believe is either nearly over a megabyte, or might even have surpassed that now) would be completely slowed down to a crawl, as a literal megabyte needs to be read/written for each and every change.

You wouldn't want to use JSON (not least, because it stinks for binary data!), but there are other options for reading/writing VFS to/from disk. Though perhaps not many for Java — what has put me off in the past here is that there is no clear solution here which doesn't involve writing a lot of additional code.

Alternatively, you do this in hand with #1456, and only save the file system on level save, which would reduce the burden of saving every time. It still means you need to keep the whole filesystem in memory, but that's not the end of the world — you're still capped at ~1MB per-computer after all.

Yeah a JSON file isn't ideal. A simpler solution would just be to encode file data instead, as it would be much simpler to implement. Base64/Base96 encoding the files would get you most of the way there as that would solve the batch file issue and
probably most antivirus warnings, although it might still show up on some of them.

Maybe base64 encoding with a custom character set, since that would prevent any form of signatures showing up and causing the OS warning.

Honestly, if someone is downloading viruses onto my MC server via CC then I would want my server's antivirus to tell me.
I can then use the existing CC tools to find out who owns that computer and perform the appropriate moderator actions.