Hugh Hood wrote:
> in article ZeadnakSH5W8HvfUnZ2dnUVZ_uCdnZ2d{at}giganews.com, Michael J. Mahon
> at mjmahon{at}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.

I've never used nulib to extract files from a .BNY archive, only from
ShrinkIt archives (with or without wrapper), so I was unaware that it
did not preserve the .BNY file info.

-michael

******** Note new website URL ********

NadaNet and AppleCrate II for Apple II parallel computing!
Home page:  http://home.comcast.net/~mjmahon/

"The wastebasket is our most important design
tool--and it's seriously underused."
--- SBBSecho 2.12-Win32