[physfs] PHYSFS_enumerateFiles does not work for me, returns "not found" for existing directory

[Jonas Thiem]

Just a small update on this: still suffering from this issue, but I
was busy fixing other things. I'll dive a bit into the physfs source
code soon and hopefully I'll be able to figure out what's going on
here!

The zip archives I tested were created with a regular "zip" utility
call (linux) and have no special things I can think of, so I kinda
doubt it's something with the archives.

On Fri, Jun 7, 2013 at 11:37 AM, Jonas Thiem <jonasthiem at googlemail.com> wrote:
> Hi,
>
> I have run into a problem with PHYSFS_enumerateFiles. I can mount and
> use my .zip archive just fine, open files for reading etc., but
> PHYSFS_enumerateFiles for the directories just won't work.
>
> My engine mounts .zip files to a random mount point, in this
> particular case it was "0553672966062338366". This is the engine
> output:
> bash-4.2$ ./ethaveon-native
> isdirectory: 0: 0553672966062338366/game.lua
> isdirectory: 1: 0553672966062338366/templates
> isdirectory: 1: 0553672966062338366/templates
> isdirectory: 0: 0553672966062338366/templates/init.lua
> isdirectory: 0: 0553672966062338366/templates/init.lua
> template init...
> isdirectory: 1: 0553672966062338366/templates
> Virtual dir templates/ found.
> previously: PHYSFS_getLastError(): (null)
> now calling PHYSFS_enumerateFiles("0553672966062338366/templates")
> afterwards: PHYSFS_getLastError(): not found
> got file list for 0553672966062338366/templates. entry filelist[0]:
> (null)
>
> As you can see, it used PHYSFS's stat to correctly identify
> "0553672966062338366/templates" as a folder. Also it identified
> various files (and opening them for reading actually works, I have
> tried). But a call to
> PHYSFS_enumerateFiles("0553672966062338366/templates") unexpectedly
> causes a "not found" error, and the returned list has NULL as first
> entry.
>
> Does anyone have an idea? I'm using the most current dev code from hg
> because I depend on the newly introduced callback-based I/O. Any help
> would be appreciated!
>
> Regards,
> Jonas Thiem
>