Re: File extraction problem

[Andy McFadden <fadden@fadden.com>]

A2Pro <a2@wilserv.com> wrote:
> ftp://public.asimov.net/pub/apple_II/unsorted/modula21.sdk
> The file I was trying to extract is "QLISTER.ABS".  Extracting the
> file with "COPY ][ PLUS  8.3" resulted in a file of the correct size
> but all the high order bits were stripped off.  "Apple II System
> Utilities Version 3.1", running on a IIgs, and "CiderPress", running
> on a Windoze machine, both extracted files that were missing the last
> 15 bytes of the source file.
> The "Apple System Utilities" was really perverse in that it stripped
> the high order bits of any bytes in the last 29 bytes of what it did
> extract.


The file contains binary data in a file of type 'T' on a DOS 3.3 disk,
which means it's not generally possible to identify the end of the file
(there's no file length included).  CiderPress takes a guess by including
all sectors in the T/S list, and then cutting off everything after the
first 00 in the last sector.  This is the correct behavior for a standard
DOS text file, which can have extra junk in the last sector, but incorrect
behavior for a random-access text file or raw binary data.

Since most of the time people are viewing or extracting documentation
in files of type 'T', I used default behavior that works best for those.

One approach that may yield better results: make a copy of the disk, edit
the file type to 'S' with CiderPress, and then extract the file.  That
should cause it to extract all sectors found in the T/S list.  (In theory
you could change the type away and back again, but that's a bad habit --
best to edit a copy of the disk so you don't screw up the original.  I
wanted to add a "revert all changes" option for disk images but never got
around to it.)

-- 
Send mail to fadden@fadden.com (Andy McFadden) - http://www.fadden.com/
Fight Internet Spam - http://spam.abuse.net/spam/ & http://spamcop.net/