Enumerate files outside of root / save directory, recursively

Questions about the LÖVE API, installing LÖVE and other support related questions go here.
Forum rules
Before you make a thread asking for help, read this.
coffeecat
Prole
Posts: 29
Joined: Sun Sep 13, 2015 4:10 pm

Re: Enumerate files outside of root / save directory, recursively

Post by 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.
Last edited by coffeecat on Fri Feb 16, 2018 3:11 am, edited 1 time in total.
User avatar
zorg
Party member
Posts: 3436
Joined: Thu Dec 13, 2012 2:55 pm
Location: Absurdistan, Hungary
Contact:

Re: Enumerate files outside of root / save directory, recursively

Post by zorg »

modiX wrote: Thu Feb 15, 2018 7:56 pm
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.
modiX wrote: Thu Feb 15, 2018 7:56 pmDisclaimer: I know it can be improved, but this won't be used in a game anyways.
Leave that to me :p
Me and my stuff :3True Neutral Aspirant. Why, yes, i do indeed enjoy sarcastically correcting others when they make the most blatant of spelling mistakes. No bullying or trolling the innocent tho.
User avatar
pgimeno
Party member
Posts: 3544
Joined: Sun Oct 18, 2015 2:58 pm

Re: Enumerate files outside of root / save directory, recursively

Post by pgimeno »

coffeecat wrote: Fri Feb 16, 2018 3:08 amI 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
Prole
Posts: 29
Joined: Sun Sep 13, 2015 4:10 pm

Re: Enumerate files outside of root / save directory, recursively

Post by 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
Party member
Posts: 947
Joined: Sat Jul 22, 2017 7:43 pm

Re: Enumerate files outside of root / save directory, recursively

Post by grump »

coffeecat wrote: Fri Feb 16, 2018 11:47 am 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
Prole
Posts: 29
Joined: Sun Sep 13, 2015 4:10 pm

Re: Enumerate files outside of root / save directory, recursively

Post by 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.
User avatar
zorg
Party member
Posts: 3436
Joined: Thu Dec 13, 2012 2:55 pm
Location: Absurdistan, Hungary
Contact:

Re: Enumerate files outside of root / save directory, recursively

Post by zorg »

pgimeno wrote: Fri Feb 16, 2018 10:25 am
coffeecat wrote: Fri Feb 16, 2018 3:08 amI 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
Me and my stuff :3True Neutral Aspirant. Why, yes, i do indeed enjoy sarcastically correcting others when they make the most blatant of spelling mistakes. No bullying or trolling the innocent tho.
grump
Party member
Posts: 947
Joined: Sat Jul 22, 2017 7:43 pm

Re: Enumerate files outside of root / save directory, recursively

Post by grump »

coffeecat wrote: Fri Feb 16, 2018 12:04 pm 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
Prole
Posts: 29
Joined: Sun Sep 13, 2015 4:10 pm

Re: Enumerate files outside of root / save directory, recursively

Post by 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.
User avatar
pgimeno
Party member
Posts: 3544
Joined: Sun Oct 18, 2015 2:58 pm

Re: Enumerate files outside of root / save directory, recursively

Post by pgimeno »

zorg wrote: Fri Feb 16, 2018 12:05 pmIf 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:
coffeecat wrote: Fri Feb 16, 2018 3:08 amThis 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.
Post Reply

Who is online

Users browsing this forum: No registered users and 58 guests