[physfs] PHYSFS_enumerateFiles: bug? debugging details, please help!

Jonas Thiem jonasthiem at googlemail.com
Sun Jan 19 11:58:33 EST 2014

Hash: SHA1

Hi *,

You may recall from the original post in this thread: I want to use
PHYSFS_enumerateFiles, on a directory at a partially random
mountpoint, in this case: "2209041615547250003/lstest/" (this is
exactly the argument I used)

However, it doesn't work:

The files inside there are named file1 and file2, but I get: ZERO
files and a claim that the folder doesn't exist, although PHYSFS_stat
confirms its existance.

The mounted archive is a zip file with the folder lstest/ and the
files lstest/file1, lstest/file2 in there. (mounted to


I tested this with Nemiver and latest physfs code (fetched from
mercurial today).

In src/physfs.c:2255, all my files inside the zip's directory are NOT
passed on, as if they were all symlinks. (if condition in that line fails)

More specifically, in archiver_zip:1654 in ZIP_stat, there is a call
zip_find_entry that results in NULL. The filename passed to it is e.g.
a suspicious "2209041615547250003/lstest//file2". (note the double slash?)

Even deeper inside, in archiver_zip.c:573 it compares the variable
path "2209041615547250003/lstest//file1" to the variable thispath
"lstest/". The result is -52. Huh. I'm a bit lost about the details
here or whether this all makes sense at this point or not. Does it
compare the right things to start with? I have no idea.

A patch/fix or any suggestions on what is going on here appreciated.

Jonas Thiem

On 07/26/2013 06:00 PM, Jonas Thiem wrote:
> 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
Version: GnuPG v1.4.14 (GNU/Linux)


More information about the physfs mailing list