Enumerate files outside of root / save directory, recursively

[coffeecat]

ffi.C does not contain symbols from love.dll on Windows, see LuaJIT documentation (http://luajit.org/ext_ffi_api.html):

ffi.C
This is the default C library namespace — note the uppercase 'C'. It binds to the default set of symbols or libraries on the target system. These are more or less the same as a C compiler would offer by default, without specifying extra link libraries.
On POSIX systems, this binds to symbols in the default or global namespace. This includes all exported symbols from the executable and any libraries loaded into the global namespace. This includes at least libc, libm, libdl (on Linux), libgcc (if compiled with GCC), as well as any exported symbols from the Lua/C API provided by LuaJIT itself.
On Windows systems, this binds to symbols exported from the *.exe, the lua51.dll (i.e. the Lua/C API provided by LuaJIT itself), the C runtime library LuaJIT was linked with (msvcrt*.dll), kernel32.dll, user32.dll and gdi32.dll.

This semantics is probably related to the fact that "Windows symbols are bound to a specific DLL name", while symbols in POSIX systems aren't.

I think the best practice is to always use ffi.load("love"). It's an already loaded dynamic library, and each dynamic library is loaded at most one time for one executable. Therefore ffi.load("love") does no actual loading.

[zorg]

EDIT: So here is my working function. I could not use isDirectory, because it was always returning false. I think this is an issue with PhysFS. I solved it by calling recursion in any case and trying to get directory items of files, too.

isDirectory may also be coded in such a way to insta-return false if the directory isn't one of the "sanctioned" ones, but i haven't checked the source, just guessing.

Disclaimer: I know it can be improved, but this won't be used in a game anyways.

Leave that to me :p

[pgimeno]

I think the best practice is to always use ffi.load("love"). It's an already loaded dynamic library, and each dynamic library is loaded at most one time for one executable. Therefore ffi.load("love") does no actual loading.

Does not work for me in Linux.

Code: Select all

$ love .
Error: main.lua:8: liblove.so: cannot open shared object file: No such file or directory

The best thing would be that Löve can mount any directory without limitation.

[coffeecat]

Oops, sorry. It doesn't work because it can't find the liblove.so. This can be fixed by using ffi.load("path/to/liblove.so"), or add the path to liblove.so in LD_LIBRARY_PATH. Now I think a conditional as suggested by grump is the best way to do this.

The best thing would be that Löve can mount any directory without limitation.

Why do you need this feature? I am genuinely asking.

I can see that a set of mount points statically specified in love.conf() for development purposes may be helpful. These mount points should be writeable via love.filesystem for soundness of LOVE API design, and the current semantics needs to be revised somehow (otherwise all writes goes to the save directory).

[grump]

Oops, sorry. It doesn't work because it can't find the liblove.so. This can be fixed by using ffi.load("path/to/liblove.so"), or add the path of liblove.so to LD_LIBRARY_PATH. Now I think a conditional as suggested by grump is the best way to do this.

I would need to ffi.load('liblove.so.0'). There is no liblove.so.

The best thing would be that Löve can mount any directory without limitation.

Why do you need this feature? I am genuinely asking.

People are not only making games, they're making tools for their games too. Every toolset needs a way to import data, and drag & drop is not a viable substitute for a file selection dialog. I also want to save stuff anywhere on occasion, when I don't wanna make my users go find the magic hidden location where the data was saved on their system.

The current state of things requires a bunch of work to get a very basic thing working. It's a major pain in the ass for no good reason at all.

[coffeecat]

I would need to ffi.load('liblove.so.0'). There is no liblove.so.

Just for your information, I have a liblove.so on my system. This is probably Linux distribution-dependent.

Thanks for the explanation.

[zorg]

I think the best practice is to always use ffi.load("love"). It's an already loaded dynamic library, and each dynamic library is loaded at most one time for one executable. Therefore ffi.load("love") does no actual loading.

Does not work for me in Linux.

Code: Select all

$ love .
Error: main.lua:8: liblove.so: cannot open shared object file: No such file or directory

The best thing would be that Löve can mount any directory without limitation.

If this only happens because you tried to do ffi.load("love") then you missed the fact that on linux, you don't do that.
Look here:

Code: Select all

local l = ffi.os == 'Windows' and ffi.load('love') or ffi.C

[grump]

Just for your information, I have a liblove.so on my system. This is probably Linux distribution-dependent.

It probably is. Is there a liblove.so.0 on your system?

[coffeecat]

It probably is. Is there a liblove.so.0 on your system?

Yes. There's also a "liblove.so.0.0.0". I am using NixOS.

[pgimeno]

If this only happens because you tried to do ffi.load("love") then you missed the fact that on linux, you don't do that.

I was just objecting to coffeecat's proposal to always load love:

This semantics is probably related to the fact that "Windows symbols are bound to a specific DLL name", while symbols in POSIX systems aren't.

I think the best practice is to always use ffi.load("love"). It's an already loaded dynamic library, and each dynamic library is loaded at most one time for one executable. Therefore ffi.load("love") does no actual loading.

My Löve binaries are statically linked anyway (because I compiled them that way), therefore there's no liblove.so to load.

The best thing to do may be to pcall ffi.C.PHYSFS_mount and try to load love only if that fails.