URFS - UnRestricted FileSystem

[Ross]

"URFS" is a small module that uses LuaJIT's FFI to bypass the restrictions on love.filesystem so you can read and write files and folders anywhere, instead of being limited to a select few folders.

It uses functions that are already included in Löve, so you don't need to add any .dlls or .sos or install anything else on your system. Everything in love.filesystem will work without modification; URFS only gives alternatives to the functions that are restricted (mount & unmount) or nonexistent (get/setWriteDir) to give the love.filesystem functions access to other directories.

See the github page: https://github.com/rgrams/urfs for the source code and documentation.

I have tested it on Windows, Mac, and Linux and it works fine for me. Let me know if you find any issues.

[pgimeno]

That's great, but it comes a bit late, and I'm pretty sure it will be affected by the Debian issue described here: viewtopic.php?p=252041#p252041

I say it comes a bit late, because Löve 12.x will allegedly come with built-in access to the whole filesystem, and I hope (crossing fingers) that it will be ready sooner than later.

[Ross]

Yep, that's true. I did run into the same issue with the Linux package myself, solved by using either of the official Löve packages from the homepage. I should look into reporting the Debian/Ubuntu versions. If you bundle for linux with an Appimage then it's not a problem for the end user.

I have also heard the rumor that this will be fixed in a future version, but considering that effort was spent to deliberately add these restrictions in the first place, I don't have my hopes up that it will be fixed a) at all, b) soon, or c) well and completely.

[slime]

I have also heard the rumor that this will be fixed in a future version, but considering that effort was spent to deliberately add these restrictions in the first place, I don't have my hopes up that it will be fixed a) at all, b) soon, or c) well and completely.

It's not fully documented yet but you can see for yourself in the love 12.0 changelog. Or in the git commit which added those changes: https://github.com/love2d/love/pull/1659

We had to modify PhysFS' own source code to make it work as flexibly as we wanted (e.g. multiple simultaneously writable mounted directories).

[pgimeno]

[...] I should look into reporting the Debian/Ubuntu versions. [...]

Forum member premek reported it: https://bugs.debian.org/cgi-bin/bugrepo ... ug=1025649

[zorg]

For the sake of completeness, there were two other solutions previously as well; NativeFS and love-fml, with the former actually going the way of calling OS native functions as well, while the latter having me do some weird stuff with PhysFS to change how the virtual filesystem worked.

Also, considering your lib doesn't change much from what PhysFS provides, did you test whether you can have multiple simultaneous write-enabled paths with your library? My assumption is that there will be issues if you have a file open (for writing, at least) in one location, and then trying to write elsewhere. This was a TO-DO in my lib that probably won't be dealt with considering that the devs implemented this feature in 12.0 as was said above as well.

[Ross]

Thanks for the replies, and extra thanks, Slime, for your response on github.

It's awesome that this has been officially added to Löve. My module will tide me over in the meantime, or help people who stick with version 11.

@zorg - Nope! PhysFS only supports one write directory (which makes sense with the current API, having no way to specify which write directory to use). I'm not offering anything else. Is there any use case for that, or is this purely theoretical? Is it even possible to have multiple files open for writing with love.filesystem? With multiple threads maybe?

If you really want to do multithreaded writing or something else that PhysFS doesn't support, then I believe you can just use PhysFS/love.filesystem to get the absolute paths and then use the lua io functions to do the actual writing.

The one and only thing my library provides, besides direct bindings to 4 PhysFS functions, is it tracks what path you mount things as. Since it only took a few extra lines to add this to my module, whereas the end user would have to create a whole other module with wrappers for each function, it seemed to make sense to add it.

[zorg]

Use-case for multiple write directories? Probably, considering that löve12 had modified physFS to include that.

Also, i believe I can't use lua io functions due to them not working as utf-8/ucs-2 (can't set the 65001 locale on my OS) so paths containing non-ascii characters fail to work, last time i tested.

[slime]

Is it even possible to have multiple files open for writing with love.filesystem?

Yep, you can just call love.filesystem.newFile(filepath, "w") twice with two different paths. No threads needed.

In fact, changing the active write directory will fail if even a single file is open for write.

[Ross]

Use-case for multiple write directories? Probably, considering that löve12 had modified physFS to include that.

No, I can see how that would be convenient, though also easy to work around—just set the directory for each file. I mean is there a use-case for what you mentioned before:

if you have a file open (for writing, at least) in one location, and then trying to write elsewhere.

When would it be required to have two files open for writing simultaneously? Why would it not be possible to write them one at a time? And if there is such a case, has anyone actually needed it for a specific project?

Yep, you can just call love.filesystem.newFile(filepath, "w") twice with two different paths. No threads needed.

Aha, gotcha, thanks. I missed that.