love.filesystem.getDirectoryItems not cross platform

Create issue
Issue #36 resolved
Seppi P created an issue

love.filesystem.getDirectoryItems seems to not be cross platform between Android and Linux (and I assume OS X and Windows. If someone could test the attached to confirm that it's an issue with love-android-sld2 and not love tip, 0.9.1.)

The directory is set up like this:


The expected result of love.filesystem.getDirectoryItems("animals/cats/") on Android is {"1.jpg"} but the actual result is {}.

I have tested this on a Linux, Android [OUYA and Samsung Stellar]. Linux produces the expected result, and Android produces the incorrect result.

Here is a Linux screenshot (0.9.0): Linux running

Here is the Samsung Stellar screenshot (last built c3a21270abcaaf8b22b94f2b7bd7aa55c607e861) : samsung stellar running

I have the feeling this may be due to the updates that effected whatever runs behind love.filesystem. I will test this against tip on both love-android-sdl2 and love.

I am marking this as a critical bug as it is a part of the love api failing, and not some system workaround. love-android-sdl2 should be as cross platform as possible.

If there's anything I can do, please tell me!

Comments (10)

  1. Alex Szpakowski

    The function hasn't changed between 0.9.0 and 0.9.1, however love-android uses PhysFS 2.1 (which is still in development) instead of PhysFS 2.0.

    It's possible this behaviour could have changed in between PhysFS versions - or maybe it's some android-specific quirk that PhysFS 2.1's code hasn't accounted for yet (I don't think there is much Android-specific code in PhysFS, if any at all.)

  2. Martin Felis repo owner

    It is a bug in physfs. The filtering of files due to symbolic links vs actual files causes the problems. One quick fix would be to simply allow symbolic links by adding

    #ifdef LOVE_ANDROID
         PHYSFS_permitSymbolicLinks (1);

    to void Filesystem::init().

    Another workaround (as you already figured out) is to make sure not to have trailing slashes.

    I have just sent an email to the physfs developers at

    One way or the other this will be fixed!

    Edit: And thanks for the test case! Helped a lot figuring out what's happening!

  3. Seppi P reporter

    @MartinFelis I'm very happy to do as much as I can. I feel rather useless, as my Java and C/C++ is very rusty!

  4. Seppi P reporter

    How are we keeping track of these changes from the actual love tag?

    I imagine tracking all these changes that we do to the source will be chaos to revert when we want to upgrade to the next version of love.

    Perhaps we should have a folder of patches that should be applied to the love branch on build?

  5. Martin Felis repo owner

    The changes related to the android port are not very extensive and are bracketed using #ifdef LOVE_ANDROID ... #endif LOVE_ANDROID.

    I have a fork of bartbes' experimental repository at That fork contains a proper android branch which is mostly based on @slime73 's mobile-common branch. Whatever ends up there will eventually end up here.

    From time to time I transfer code from this repository to love-android and vice versa (somewhat outdated atm however). Creating patches to the official LÖVE is very easy using my love-android repository.

  6. Seppi P reporter

    Ok, cool, so long as there is a plan of action for providing upstream or pulling downstream.

  7. Log in to comment