The test was expecting the order of threads not to change, which
was reasonable until we started throwing fake threads at it with
the recent change to "mask dataless". We now employ a hack that
reorders the CRCs from data-class threads so that the data fork's
CRC always comes first. Not a tremendously robust solution, but
it'll do.
When GSHK adds files to an archive, it doesn't create threads for
zero-length data and resource forks. NufxLib had a workaround
for this, but it wasn't handling all possible cases. We now
fully handle "Miranda threads" (if you cannot afford a thread,
one will be provided for you).
This broke test-basic, because a callback gets called one extra
time now due to the additional thread. It also broke test-twirl,
which uses "mask dataless" and is sensitive to the order in which
threads appear. (test-twirl actually works just fine, but the
CRC check is too simple-minded, and is arguably incorrect.)
Since this can apparently break things, I'm making this a minor
version bump, to 3.1.0-a1.
I also tweaked the NuLib2 file listing to test for the extended
file storage type, rather than simply scanning for data threads.
Forked files are now listed as such, even when they're missing
the actual resource fork data thread.
Updated the NuAddFile command to take an extra argument that
identifies the source as coming from a resource fork. You can't
actually use this to create a forked entry without some behind-
the-scenes renaming, because the exerciser uses the disk filename
as the storage filename, and the "add file" code won't be able to
match the entries up.
Some fixes to the Mac OS X build:
- Replace the Carbon calls that were used to set the creator
and file type with xattr calls. The Carbon stuff still worked
but caused deprecation warnings. Stop linking against Carbon.
- Correct the way resource forks are accessed (from "/rsrc" to
"/..namedfork/rsrc"). The native resource fork support is
incomplete and doesn't work quite right, so it's now disabled.
(Which means the corrections to the file name don't actually do
anything, but you can at least play with it.)
- Correct the file/aux type conversion, which appeared to do
useful things but actually didn't in some circumstances (e.g. when
adding files, the code for acquiring the file types needs to be in
NuLib2, not NufxLib).
- Set creator and file type to 'pdos' values when extracting from
a Binary ][ archive.
Also, drop some old purify/quantify stuff.
NufxLib has historically made no effort to distinguish between
the character set used for filenames on the local disk, and for
filenames stored within the archive. Now all Unicode filename
strings use the UNICHAR type and have "UNI" in the name, and all
Mac OS Roman strings have "MOR" in the name. (The naming
convention makes it obvious when you're assigning the wrong thing;
on Linux both formats are char*, so the compiler won't tell you
if you get it wrong.)
The distinction is necessary because filesystems generally support
Unicode these days, but on Windows you need to use a separate
set of wide-character file I/O functions. (On Linux it all works
with "narrow" strings, and the UTF-8 encoding is interpreted by
applications.) The character set used for NuFX archive filenames
is MOR, matching what GS/OS + HFS supported, and we want to be able
to convert back and forth between MOR and a Unicode representation.
This change updates the various character types and string names,
adds conversion functions, and updates NuLib2 for proper execution
on Linux. It does not include the (probably extensive) changes
required for Windows UTF-16 support. Instead, the conversion
functions are no-ops, which should result in NuLib2 for Windows
continuing to behave in the same slightly broken way.
This adds "test-names", which exercises Unicode filenames a bit.
It will not pass on Win32.
Also, tweaked the Linux makefiles to have explicit dependencies,
rather than empty space and an expectation that "makedepend" exists.
Also, minor source code cleanups.
While this probably doesn't affect binary compatibility -- it's
mainly a matter of naming and string interpretation -- there's
enough going on that it should be considered an API revision, so
this updates the version to 3.0.0.
