AppleCommander issues

[IvanExpert]

I'm putting this all in a single issue, since they should probably be broken out separately in the AppleCommander repo issue tracker; I'll leave that to you, Joseph.

AppleCommander issues:

Which is the correct distribution source? http://applecommander.sourceforge.net (.13/.13id), or https://sites.google.com/site/drjohnbmatthews/applecommander (.14) ?

Enhancement: extended (forked) files are currently only supported via -convert, which creates a new disk image. Need to be able to copy extended files into existing disk image. Should accept AppleSingle, MacBinary, or an argument to indicate incoming stdin file is resource fork and create extended file out of specified file (argument parameter) within the image (or complain, or replace the resource fork, in the case of an existing extended file).

Enhancement: recursively copy a ProDOS volume or subdirectory from one image to another; additionally, would be nice to do same from the actual current filesystem from Nulib2 extended filenames.

Enhancement: support writing GS/OS lowercase filenames. See http://www.1000bit.it/support/manuali/apple/technotes/gsos/tn.gsos.08.html

BUGS:

In 1.3.5.13 (fixed, AFAIK, in 1.3.5.13id and I think 1.3.5.14): When ac creates a subdirectory, e.g. via "ac -p imageFile path/to/prodosName", it writes the PARENT_ENTRY field in the subdirectory headers incorrectly; the value it writes is one less than it should be. At minimum, this will cause the GSOS installer to report that the directory is corrupted if it tries to copy anything a directory created by ac. I assume that this bug is because it follows what Beneath Apple ProDOS says on page 4-30, but Beneath Apple ProDOS is wrong; the parent directory's header counts as 1, not 0. They mentioned this in the errata of their second supplement, and in any case simply making a subdirectory using any version of ProDOS and then examining the header reveals the book to be incorrect.

In 1.3.5.13 (but partially fixed in 1.3.5id and I think 1.3.5.14): "ac -convert archiveName ImageName" will omit any files in a ShrinkIt archive that have a resource fork, but no data fork. (If the archive contains a zero-length data fork, it doesn't skip, but instead dies with "Error: null".)

How to make a test archive to work with:

echo datastuff > myfile#000000 echo resourcestuff > myfile#000000r nulib2 -a -e myarc.shk myfile#000000 (make myfile#000000r file zero-length, or delete it, to trigger both versions of the bug)

Or, if you have a GS, get spectrum deluxe from ewens site, look in spectrum.2.5.3/misc/support/hierarchical, and use GSHK to archive it. That file has no data fork.

In 1.3.5.13id and I think 1.3.5.14: The fix for the missing or zero-length data fork issue is itself a potentially file-corrupting, data-destroying bug, but not one that affects how I'm using it.

In the case of an extended file with a zero-length data fork, what AC should do is create a new seedling for the data fork, allocate it as in use, and write the relevant data for it ($0: type is seedling, $1-2 block number of seedling, $3-4: 1 block used, $5-7 zero length) to bytes $000-007 of the extended key block.

I have two different reports on what it does differently, and I don't know which is accurate; it may be that one is in 1.3.5.13id, and one is in 1.3.5.14. They're both dangerous and incorrect, and in both cases a seedling doesn't get created. The first (.13id?) is that zeroes are written in into $01-07 of the extended key block. The other possibility (.14?) is instead of the block number for the seedling in $1-2 of the exgtended key block, instead the block number of the extended key block itself is written.

This is ok as long as the data fork of one of these files never gets written to. But if it does...in the first scenario, in the resulting image, every extended file with a zero-length data fork actually consideres its data fork to be stored in block 0. If the data fork were to be written to, it would overwrite block zero, rendering the disk unbootable. Further, if any other extended files with zero-length data forks have their data fork subequently written to, they would overwrite the data in block zero written by the first file. Or, in the second scenario, it's even worse; writing to the data block would overwrite the extended key block, meaning any attempt to read from or write to either fork would in fact be referencing a random part of the disk.

In all versions (13/13id/14): In both the data fork and resource fork mini-entries of the extended key block, AC does include the index blocks (and the master index block, in the case of a tree) in the total block count for that fork in $03/$04. The block count is only representing the file data. (However, the total block count in the actual file entry for the file is correct.) Consequences of this are unknown, but at any rate it's wrong.

In all versions (13/13id/14): Extended files are shown with their actual file length in the file entry. Correct behavior (not documented anywhere, but exhibited in all versions of ProDOS 8/16/GSOS) is to write $000200 as the file length in the file entry for extended files. The actual file length of each fork is represented in the mini-entries of the extended key block. Consequences of this are likely to be minor, but it's still wrong, and I don't know what would happen with extremely large files where the total number of bytes would exceed the 16M that are representable with three bytes (e.g. because each fork is a tree).

In all versions (13/13id/14): Writing ProDOS sparse files isn't supported during -convert. It would be nice if, when using -convert (meaning it's not relying on stdin for its input file), if it sees a file with a block number of 0000 in an index block, it writes it out that way in the target index block, rather than expanding it to a block of 0's which is then listed in the target index block, which expands the file size rather than preserving the original file size. Reference: http://www.gno.org/pub/apple2/doc/apple/technotes/pdos/tn.pdos.030 http://www.easy68k.com/paulrsm/6502/PDOS8TRM.HTM#B.3.6

In all versions (13/13id/14): -convert will not only not add files to an existing ProDOS disk image, it will silently overwrite it, which is less than great.

In all versions (13/13id/14): ac -convert can't operate on a GS-Shrinkit .sea file (what you get is a copy of the .sea file). It can be worked around by using nulib2 -xe on the archive, and then making a new archive from the extracted files using nulib2 -ae Example: http://nulib.com/library/gshk11.sea

[knghtbrd]

a2commander: 1.3.5.14 is current release candidate, but it appears that Dave Schmidt is the only one working on it at all these days, kind of adopting it. I've mentioned elsewhere that I'd like to see it move to github, if Dave's comfortable with using it. It's still hosted on CVS of all things. shudder It's hard to even find a cohesive history of changes.

[knghtbrd]

SF is where the repository lives however.

[knghtbrd]

Status update: Not much has changed here. AppleCommander still has bugs, has not had a new release, and it's all still ambiguous. Marked the issue as a bug since that's the most important problem for us with all of it.