This sounds harmless, but it actually forces a write of the inode's atime,
which means a lot of painful and unnecessary disk i/o on some filesystems.
Should be a good speedup on games that read a lot of small files on Unix.
This lets an application supply its own archivers, where they will work like
any built-in archiver. This allows abstract directory interfaces the same
way that PHYSFS_Io allows stream implementations.
This is a work in progress still. The API is still changing, and will remain
at version 0 until it is finalized (a theoretical future version 1 will be
for when the final public interface changes, not when we evolve the initial
API design).
This would try to build something under the basedir for Windows 95, OS/2, etc,
but those targets are gone now. Modern systems provide this. If a given
system can't in the future, they can pull this code out of revision control
and use it in their implementation of __PHYSFS_platformCalcUserDir().
This change let me remove __PHYSFS_platformGetUserName(), too.
It's only used by archive_dir.c, and it's trivial to make it into
platform-independent code for that one module.
Bonus: less malloc() pressure...now every access to the native filesystem
doesn't require a temporary heap allocation.
Instead of trying to deal with a count of objects, just give 'em a stream of
bytes. This is WAY simpler to work with at the implementation level, and
removes confusion about what to do with a partial read.
This will be very useful when we expose the i/o interface to applications.
Ryan C. Gordon