[physfs] Mounting Archive from within an archive
Ryan C. Gordon
icculus at icculus.org
Mon Aug 30 04:35:09 EDT 2010
> So now I wanted to add archive support. Many missions usually are shipped as
> ZIP which contains the HOG-files and other info.
> My idea is to mount such a ZIP to" missions/" and then open the HOG whenever
> it's needed.
Following up...this now works in revision control. I couldn't sleep one
night so I decided to rip a bunch of stuff up.
There's a new interface available to apps, PHYSFS_Io, which is a bunch
of function pointers for read/write/seek, etc. You can fill them in and
pass it to PHYSFS_mountIo(), which is basically PHYSFS_mount(), but
instead of a real file, it operates on the PHYSFS_Io.
That's a low-level interface for unusual applications. All the archivers
now use it behind the scenes, instead of __PHYSFS_platformRead(),
etc...most applications will never use it; the existing APIs will remain
and be supported as first-class functions as usual.
There are a few uses of PHYSFS_Io that I suspect will be common enough
to provide them in PhysicsFS itself, though. They'll use PHYSFS_Io
behind the scenes so you don't have to.
PHYSFS_mountMemory(): works like PHYSFS_mount(), but takes a memory
buffer instead of a file, so you can have an archive that's not backed
by a real file at all. All i/o will be done only to RAM.
PHYSFS_mountHandle(): works like PHYSFS_mount(), but takes a
PHYSFS_File* instead of a file, so you can trivially have an archive in
Both are testable from test_physfs.c. This, for instance...
mountmem $REAL_FILENAME / 1
...will load $REAL_FILENAME into RAM, close the file, and pass it to
...and this is a bit more complicated...
echo "testing 1 2 3" >file.txt
zip -9r inner.zip file.txt
zip -0 outer.zip inner.zip
mount outer.zip / 1
mounthandle inner.zip / 1
The only other immediate use I'd see for PHYSFS_mountIo() would be some
sort of encryption scheme. archiver_zip.c doesn't know the bytes it is
reading are encrypted on disk, because the PHYSFS_Io is decrypting them
as needed. As far as the .zip archiver is concerned, it's just asking
for more bytes from a PHYSFS_Io like it always does.
The next major step after this is exposing PHYSFS_Archiver, and letting
apps register their own file formats. PHYSFS_Io handles the transmission
of data, PHYSFS_Archiver turns that data into some meaningful structure.
I haven't started on this, but it should be a less traumatic change than
Please note that these new APIs are still subject to change, and
comments on them are welcome.
(If I have another sleepless night, I really need to merge Christopher
Nelles's patches, though. I haven't forgotten it, honest!)
More information about the physfs