Regardless of what the 3.0.0 documentation says, PhysicsFS never handled this
correctly, so now we check for it so you can't get into crashy situations.
Corrected documentation to reflect reality.
(transplanted from 0bbfaf6c5508139ba3d417377c94d75ca921772a)
So if a zip file goes to the zip archiver but is corrupted, the system can now
know not to bother trying other archivers once the zip archiver has had a shot
at it, and just as important: it can report the real error from that archiver
instead of a generic "unsupported."
Now callbacks can stop further enumeration and report errors, if they had a
catastrophic issue or just found what they needed and don't need to process
any more items.
Also, the actual enumerators can report errors instead of silently dropping
items. This led to several other fixes as all these implementations got
audited and reworked.
The original, non-callback enumerator now returns NULL if it can't produce a
complete list instead of dropping items and returning a partial list.
- Dramatically reduce RAM usage: uses between 8 and 11 kilobytes less static
memory for its internal case-folding tables.
- Actually works now. It would fail unconditionally if a codepoint folded
into multiple codepoints, even if the compared string contained those exact
codepoints.
- Now a public API!
- Removed __PHYSFS_utf8strnicmp(): nothing was using it, it was incorrect
anyhow, and what does 'n' represent when either string might case-fold to
something larger in-flight, anyhow?
With the release of ArcaOS, this is a live platform again.
This code probably doesn't compile yet; I've just given it a first shot at
resolving the changes between the last OS/2-supported revision and now.
This still needs Unicode support added in any case.
To use: mount a .zip file as usual, open a file as usual, but append '$' plus
the password to the end of the path, like so:
PHYSFS_File *f = PHYSFS_openRead("/path/to/my/file.txt$MyPassword");
Note that this is the "traditional" PKWARE crypto, like you might get from
PkZip 2.04g or Info-ZIP. They have more advanced cryptography in the modern
.zip spec, but that's not implemented here. If you've ever tried to unzip
an archive and were prompted for a password, you probably saw the traditional
crypto at work.
Note that this is NOT a secure thing: if you ship an app that contains a
password, someone with a debugger can retrieve it. Note also that this
password could be available to any code registered as a PHYSFS_Archiver, and
that due to how archives combine into a single file tree, the wrong archiver
can get the password, at a minimum causing it to fail because passwords don't
match.
In short: make sure you know what you're doing before you use this!
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).
Ryan C. Gordon
Francesco Bertolaccini