mount points, etc...

Ryan C. Gordon icculus at
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("", "/mods/alien_swarm", 1);

...mounts at /mods/alien_swarm. /mods and /alien_swarm don't 
have to exist, but they will be treated as real directories as long as 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("", 1) is like 
PHYSFS_mount("", "/", 1).

So with the mount version, if 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(""), which, in this case, 
returns "/mods/alien_swarm".

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 mailing list