Add very basic and sandboxed FileSystem support

Feature Requests Engine Features
1

As a Roblox developer, it is currently too hard to work with DataStores. Not because they are complex, but because they are too limited. a few MB per player is NOT good for me, and the place has a DataStore limit.
We need a basic FIleSystem support.

  1. Player joins the game, game warns them that the game uses localized File System.
  2. If they go ahead, the game will create or use the existing folder that is relative to the GAME they are playing. For instance, if I am to call a function like
-- LocalScript
game.CreateFolder()

It will create a folder in the Roblox folder that corresponds to the game. The game can ONLY access its own folder. It will be named as the game ID.

  1. Functions could look like
game.CreateFolder()
local FileSystem = game:GetService("FileSystem")
FileSystem.mkdir("/Folder") -- / Represents the game folder.
local fref = FileSystem.open("/Folder/file.txt", "w") --[[
Create file and open if it doesn't exist.
Open file only if it does.
]]
fref.read() -- Get string data
fref.write("Hello world") -- Write "Hello world" to the file
fref.append(" -- Another hello world") -- File will now contain "Hello world -- Another hello world"

  • More security:
    – Make sure this file system only works in the game foler.
    – Only give users RW (Read Write) and no X (Execution).
    – No permission to create .exe files

  • Use cases:
    – Save data locally. Much less limits. Much faster reading/writing data.
    – Create drivers. If your game is a car game, you could create a small driver that people can download for their steering wheel written in something like C++ that writes data to that folder that our game can read and use.
    – Output. A game may be detective based and it may output a file that the user can open and see what it is.

It would benefit me in the OS simulation I am developing. Having to save people’s data on my cloud servers feels like too much and too unsafe. Saving it on their own device, instead, makes it much better.

17 Likes
2

Hey! I get your idea, but I think Roblox DataStores are actually great as they are. Storing local files for each player can create a lot of problems, especially if you start saving complex objects—like in Java, storing objects directly takes up a ton of space.

On Roblox, the best practice is to use JSON for everything. It’s much lighter and works perfectly for most use cases. Personally, I’m developing a game and have access to over 200 GB, but I barely use 300 MB in my DataStores.

Roblox’s limits aren’t meant to annoy us—they’re there to make developers more responsible. It forces you to manage data efficiently instead of just storing everything everywhere. So even though a local file system might seem convenient, DataStores remain the safest and most effective solution on the platform.

5 Likes
3

Hey there! I get what you mean! For your use case, DataStores are perfect and I completely get you! But for my use case, I need to store up to 128MB per player, that is a lot and in the DataStore section Roblox only gives me 102MB.
Plus they would open up a ton of ideas and new stuff that could be done with the platform
But I completely understand you

2 Likes
4

What if a player modifies this file to be something it shouldn’t?

Good idea, but it shouldn’t be on a platform like Roblox.

2 Likes
5

Here is the thing, if you read my post again, I have written that a game can only modify files in it’s own folder. Anything in that folder written, belongs to the game. The game can not write to another game’s folder. If a player modifies a file to something it shouldn’t, the game will lose functionality for the player. This is where the game takes responsibility to make an actually accountable use of this. This file system should not have anything to do with the Server.

2 Likes
6

That’s…not what I said.

{
    "foo": 10
}

This is supposed to be a number.

Now, the player changes it to a string.

{
    "foo": "bar"
}

What does your game do? Reset it to the default? Error and kick the player?

Not only that, but what if the game has bad logic and keeps creating new files, bloating the player’s computer?

1 Like
7

Alright.
First off, with your first argument, it could be fixed with basic redundancy from a good game.

game.CreateFolder()
local fs = game:GetService("FileSystem")
local http = game:GetService("HttpService")
local fref = FileSystem.open("/playerjsondata.json", "r+")
local jsondec = http:JSONDecode(fref.read())

if type(jsondec.val) ~= "number" then return end -- or any error handling

As a fail safe for the “keeps creating new files”, Roblox should notify users every time like 32MB is written and ask if the user would allow 32MB more to be written. This is to make sure it can not bloat the player’s computer.
This is only for saving extremely long data and adding some new functionality to roblox.

3 Likes
8

That makes sense.

I think this should be limited to plugins, though.

9

As interesting of an idea this is, I personally don’t think this should be added. We have plenty of storage via datastores and anything that’s stored on the clients pc, can be modified by the client, e.g through a text editor meaning we cant trust it. You can still check its type but ultimately you wont know if its been modified with and many people might not want data stored locally. I personally think you should at look at optimizing the data your storing as 128MB is a lot and I wouldn’t want one specific game to store 128MB on my device.

2 Likes
10

Thanks for the reply! There is no way I can optimize the data of my game as most of it is literally data, and till now my only solution was to use an external server that I host and I bypass roblox limits

11

The file size limit goes up with the amount of players your game gets.

12

If this ever gets implemented, even with warnings and so, it’s just a disaster waiting to happen, a liability.

Raw filesystem access, even if protected, is risky; just ask exploiters. They have filesystem issues every second. People will always find a way around the security you may implement.

None of what you pointed out for security address anything. The first simply says ‘the game can only read its own data’ which is basic in design, this doesn’t prevent a player from malforming the data, changing it, …; which completely violates data integrity for your game and could cause errors, crashes, etc, second, Windows, the main platform Roblox runs on, and its filesystem don’t care to distinguish between executable and read/write files, which makes the second point irrelevant almost, and even then if we were on MacOS, it’s a nobrainer to create the files being RW only, the user would (ideally) never touch that folder asides from the game itself manipulating the data, so execution permissions are off the picture. Even if you do something such as revoking EXE creation, which won’t really help you at all because DLLs, SYS files and a bunch of other files that can be repurposed as potential malware entry points exist. Something as innocent as a zip can be used as a zip bomb, such attack isn’t complicated to carry out anyway.

Faster reading and writing is highly variable; it depends on a variety of factors, and you may be disappointed in the real outcome, since Roblox datastores are, 100% true databases which work at larger scales and RCC probably has replicas nearby to speed up look-ups, which could prove to make it slower than you may be lead to believe.

Creating drivers is completely out of the picture, you would have to somehow get roblox to allow you to tell people to download external files freely on a released game, even if that’s allowed, file based communication like this is extremely slow for something real-time such as a steering wheel. It’s much more realistic to request something such as WebSockets for it, which even then is still too slow, and the last is an ARG, I haven’t really seen any ARG games, but it’d be interesting though.

With some modifications it could prove a good request, although knowing Roblox, if they tried to ‘protect’ saved data, it would be with the built in cryptography of windows tied to the user, which is the same thing they use for ROBLOSECURITY cookies, which you can trivially decrypt with less than 60 lines of C++, they would have a really hard time achieving data integrity, unless true cryptography is used in a per game basis, in which a keypair is generated (potentially per user) the data integrity will never be something you can guarantee.

Other users have laid out similar concerns, but it all comes down that we have people that are willing to fill their computer with viruses if it means 1% more chance at getting a PET SIM 99 rare pet, what makes you think that people won’t waste their time trying to figure out how to crack your save file just to get infinite gold or something?

It’s good in paper, but in reality, there’s so many caveats it’s probably too much of a hassle to carry out in my opinion.

11 Likes
13

i really like the suggestion, but as storing game settings, so here’s my variant of API:
Each game has only 1 global file with size of 4096 bytes limit.
Byte limit is so low because you don’t really need that much for setting configurations.

FileSystem:SetFile(Table) - accepts only table, converting into a json string. Errors if limit is exceeded
FileSystem:GetFile() - returns a luau table

local FileSystem = game:GetService("FileSystem")

local Table = {
	SoundsVolume = {
		[".Effect.Sound1"] = .1,
		[".Effect.Sound2"] = .5,
		[".Effect.Sound3"] = .2,
		[".Stuff.Sound2"] = .2
	}, -- you could use sound groups as well
	Settings = {
		[1] = true,
		[2] = false,
		[3] = true,
		[4] = false,
	}
}

FileSystem:SetFile(Table)

------------

local Table = FileSystem:GetFile()

Obviously that table is not memory efficient as example at all and this shouldn’t be used anything important, but the point is that it’s nice to have client settings not stored at roblox servers, as giving more freedom and easier to add more settings/customization without worrying to bloat datastores. Also, there will be an option in roblox client to clear the files.
That’s my vision for this request, but i understand that it would open pandora box.

1 Like
14

I could definitely see this feature be useful for things like local settings. Using network bandwidth and datastore capacity to store how loud the user wants their volume to be or if they want their flight controls to be inverted seems like a waste. A very small waste, mind you, we’re talking kilobytes here at most, but it would still be a nice-to-have.

15

me when a write a virus onto someone’s computer
me when i turn my game into a fork bomb and blow up someone’s hard drive

there are so many issues with implementing a system like this and datastores are perfectly fine if you’re smart about how you use them so it’s just not worth it

1 Like
16

I like how most of the arguments from people here come from a position of how they think things should be stored, and how they store things.

File system access, particularly for single player games, is extremely common in video games and there absolutely is a use for it. Trying to argue against this is like saying you use OOP, OOP works great for you, so why use anything else?

There are some real arguments here against it such as malicious use, but that leads into a whole other rabbit hole. Should roblox have removed private modules because some people used it maliciously? I say no. Should Roblox avoid implementing file system access because some people will use it maliciously? I say no. Should roblox make sharing animations difficult because some people use it maliciously? Yeah, take a guess as to what my answer is

17

The point people are making here is that the use cases OP is asking for is either better suited for a more dedicated, less easy to exploit API (local settings or save data shouldn’t need a file system API which can go horribly wrong if a sandbox escape is found, and “creating drivers” you don’t even need to explain why that is a horrible idea for a game to be able to do).

This entire feature request doesn’t really make much sense and OP would have been better off proposing the problem they face (saving local settings or save data) and asking for Roblox to provide a solution than to propose a solution outright that is horribly overscoped for what they want to solve.

18

This falls under what I said about people being malicious. Sure, some people would use the implementation described by OP to do bad things, but… should the rest of us be cut off because of the bad actions of other people? I suppose we can agree to disagree on that part, because my answer will always be no.

19

I’d personally just argue that he’s provided no valid use cases that justify a full file system API that aren’t better solved with their own dedicated solutions (even to the end of creating drivers, the example he provides there should be solved with first-party support for steering wheel devices, something which a feature request already exists for too).

The last “output” one doesn’t really make much sense either and would be solved by an implementation of a local settings/save data API anyway.

2 Likes
20

Malicious actors are a potential issue, but also not really. Roblox just has to implement a reliable and secure API for it. Zip bombs aren’t an issue if the code detects them early. Remote execution can be a potential issue, but it requires the device to already be infected by an external virus for it to run. But Roblox would be liable for spreading that malicious code and transmitting stolen data.

2 Likes