mount points, etc...
Ryan C. Gordon
icculus at clutteredmind.org
Wed Mar 16 07:32:31 EST 2005
(This email never seems to have made it to the list...edited, updated
and resent... --ryan.)
...the initial mount points code is in Subversion. It's based on
Philip's patch, but there were about a thousand corner cases I needed to
handle, and some internals had changed dramatically (and, y'know, I
can't leave well enough alone...)
There are some notes. This call:
PHYSFS_mount("myarc.zip", "/mods/alien_swarm", 1);
...mounts myarc.zip at /mods/alien_swarm. /mods and /alien_swarm don't
have to exist, but they will be treated as real directories as long as
myarc.zip is in the search path...this means they will be recognized by
PHYSFS_exists() and PHYSFS_isDirectory(), etc.
The easiest way to understand the use of mount points to your
applications is this: PHYSFS_mount is like PHYSFS_addToSearchPath(), but
every file in the archive will have /mods/alien_swarm prepended to it.
Conversely, PHYSFS_addToSearchPath("myarc.zip", 1) is like
PHYSFS_mount("myarc.zip", "/", 1).
So with the mount version, if myarc.zip contains "data/aliens.txt", then
you could access it with
PHYSFS_openRead("/mods/alien_swarm/data/aliens.txt") ... The
addToSearchPath version would use PHYSFS_openRead("/data/aliens.txt").
There's also PHYSFS_getMountPoint("myarc.zip"), which, in this case,
The immediate use for this is to let you sandbox external content...if
you let people download packages into your game/app, then you can use a
mount point to guarantee it won't conflict with existing packages. There
are other creative uses that let you organize content more precisely
than you can with just the ability to stick new archives at either the
start or end of the existing search path.
I've only tested it briefly, and I'm sure there will be bugs. Please
pound on this and let me know what blows up.
Also new: MPW support for MacOS Classic, Brazillian Portuguese
translation, and some other minor fixups.
More information about the physfs