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

[Jonas Thiem]

-----BEGIN PGP SIGNED MESSAGE-----
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
2209041615547250003/lstest/)

DEBUGGING DETAILS:

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.

Regards,
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
>> 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.14 (GNU/Linux)

iQIcBAEBAgAGBQJS3AQqAAoJEBIDTbbx8YkeJxgQAOIH3/T81z6HJqANnRfAFA9c
KtpALcEG4JvVH0xSZqh+2N3M/5Y3fxO32FlXa6Hq3YF5mIPfir30L3GXkcH+1XJS
DqrOMssASgNpWetL0snnn980iCXv2yVzlmBicvqFXXQoV8Ym6txfcI0nuMMOuIhu
T7iJ2n93TxnnCrDX9qADYC7/uUaVGyZgsBnwM94GbFl56NttnXNbvc7hlXr/Kdi8
PnmOotVHNltW8RXuiMXPyFkxumKlTDbabNebapiL5TdW8uqvm1uWhnQQKLEL0E8i
7Fap/J/mM8Yhi4VpLsA/YYVSMOjFice0lG0fdLg1XgVTu7mVc49Ecv1eZjKAWvDE
cDxSVagzhhiQqORU7Dala80SJ/eFZJhIsPFM/kQMQeoOmXYJIHE1RPQFDnssarzu
Zth1QWJFGA0FSouLxLtCtSmXpLbTKuM+T3eSYqcPzAk9ivXZXNLAyv1sNFcwH+OS
ejqui8kjZcCoirhKzoQnHwtUA/Y8uRNNjLJ9hLBY6SbOyDaM3/Jk/Q5YHJ3FgsY6
pVYQcNSgjwyLpF6BHjk92xftJbPFU0s3lcrsfXGmpJDJMsA/aAm9aVI4b1W7mmIm
zs2OnShevJRrtE47SJR5LBj1zzUsUhlLCu00LpCnNMbQlZET2+/XUfF/utDFmshW
AziSbxc55/qycDmbX5C/
=44Sd
-----END PGP SIGNATURE-----