Add in LuaFileSystem

FiveM Discussion Platform Suggestions
1

In C# its easy to get the current working path, illiterate through a folder, and more. It would be amazing to be able to easily do this with LFS.

2

I think you can already use the builtin io lib from lua, although it may not have all features enabled.

3

Its limited, but ill see if I can do what I want with that. Kind of forgot about it since i’ve been using lfs a lot lately. Mainly looking to get the current runtime directory too…

3 Likes
4

This is not 100% IO but it is a file system of which I have used before. Below is a snippet of it…

file = io.open("Stored-IDs.txt", "a")
    if file then
        file:write("Name: " .. name .. " ID: ".. identsList )
    end
    file:close()

Reference: https://www.tutorialspoint.com/lua/lua_file_io.htm

It’s been a while since I did that but it should work still.

1 Like
5

That is the same as I linked above…?

2 Likes
6

Ye. Examples help :stuck_out_tongue:

7

Yeahh… dont suppose you can get all the files in a directory can ya? xP

8

Haven’t tried this, but I found this scandir implementation a while back that should get all of the files in a directory.

-- Lua implementation of PHP scandir function
function scandir(directory)
    local i, t, popen = 0, {}, io.popen
    for filename in popen('dir "'..directory..'" /b'):lines() do
        msg(filename)
        i = i + 1
        t[i] = filename
    end
    return t
end
1 Like
9

I wonder what this does in Linux…

10

I shall bump thee! Riiiiise from the graaaave!

The ability to list files without relying on popen would be great.
It’s already available in JavaScript/Node, so I don’t think we have any extra security implications to worry about from including LFS server-side?

11

Let’s summon @gottfriedleibniz, our resident Lua module auditing contributor for this one.

I do feel that LFS’ file enumeration was slow on Windows, a proper WinAPI loop is perhaps better there.

1 Like
12

Coincidentally, LuaFileSystem (https://github.com/keplerproject/luafilesystem) has been recently updated and (1) takes advantage of 54’s __close metamethod; and (2) finally fixes symlinks on Windows.

In my opinion, support for __close is important because it idiot-proofs one more susceptible parts of that API, i.e., iterating over large directory structures (and/or acquiring filesystem locks) and the implications of doing something wrong. For example, inexplicably breaking from the iterator and being beholden to the garbage collector to close the resources for you.

That being said, I don’t see anything within that repository preventing us from using that library as is; at least not for Lua54. It is certainly better than the OS-specific pcall “stuff” that is required now.

Edit: After further inspection/testing, that repository will need a little bit of cleanup:

  1. Actually support Unicode, related: https://github.com/keplerproject/luafilesystem/pull/57
  2. Cleanup some issues w/ errno (e.g., the Lua API may change this value and the library isn’t caching it in places).
  3. Use the more secure/defensive stdlib functions.
2 Likes