Re: Transferring disk over serial port through PC's standard i/o?

[Hugh Hood <hughhood@earthlink.net>]

in article ZeadnakSH5W8HvfUnZ2dnUVZ_uCdnZ2d@giganews.com, Michael J. Mahon
at mjmahon@aol.com wrote on 1/11/09 5:39 PM:

> That's because the uncompressed files in the .BNY wrapper depend on the
> wrapper to hold their file info.
> 
> ShrinkIt compressed files (in the .BXY wrapper) use the wrapper to hold
> only the ShrinkIt archive file info, which ShrinkIt doesn't really need.
> The ShrinkIt archive itself contains the file info for all the archived
> files.


Michael,

You are certainly correct, but I believe I should clarify exactly what the
problem is.

Below I've listed the shell output of the nulib2 -v (view archive contents)
command applied to the same file.

The first listing is for an AppleWorks Word Processor document
_uncompressed_ in a Binary II wrapper (read.me.BNY). The second is for the
same file _compressed_ in a Binary II wrapper (sread.me.BXY)

Both files were sent with zmodem to a Mac OS X machine from an Apple II with
ProTERM. On the Apple II, the 8-bit Shrinkit created the compressed file,
and ProTERM added the Binary II wrapper to both files upon transmission.


START-----------------------------------------------------------------------

nulib2 -v read.me.bny

read.me.bny                                                 Files:    1

 Name                        Type Auxtyp Modified         Fmat   Length
-----------------------------------------------------------------------
 READ.ME                     AWP  $0000  16-Jun-96 11:52  unc      3603
-----------------------------------------------------------------------


nulib2 -v sread.me.bxy

sread.me.bxy    Created:11-Jan-09 13:35   Mod:11-Jan-09 13:35    Recs:    1

 Name                        Type Auxtyp Archived         Fmat SizeUn-Length
----------------------------------------------------------------------------
 READ.ME                     AWP  $0000  11-Jan-09 13:35  lz1   57%     3603
----------------------------------------------------------------------------
 Uncomp: 3603  Comp: 2071  %of orig: 57%


END-------------------------------------------------------------------------


Notice that in _both_ cases, nulib2 is intelligent enough to determine the
Type, the Auxtype, and the date(s) for the file.

The problem is that when nulib2 actually extracts the files (nulib2 -x
filename), ONLY the .BXY file will have this file info preserved for Mac OS
X/HFS. The .BNY file is extracted with NO preservation of the attributes
(creator/file type/etc).

In summary, even though nublib2 recognizes the file type info for .BNY
files, and thus is seemingly capable of preserving this information in the
files it writes, it does not.

Hugh Hood...