Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!caip!brl-adm!brl-smoke!smoke!towson@AMSAA.ARPA
From: towson@AMSAA.ARPA (SECAD)
Newsgroups: net.micro.cpm
Subject: [Keith Petersen:  Bad files in <CPM.TURBODOS-SIGI>]
Message-ID: <2835@brl-smoke.ARPA>
Date: Wed, 6-Aug-86 15:58:15 EDT
Article-I.D.: brl-smok.2835
Posted: Wed Aug  6 15:58:15 1986
Date-Received: Sat, 9-Aug-86 06:25:58 EDT
Sender: news@brl-smoke.ARPA
Lines: 53

Fellow CP/Mers - A couple days ago I sent Keith Petersen a message (with a
copy to this list) describing what I perceived to be a problem with certain
squeezed files in the <CPM> archive.  Basically, when I tried to unsqueeze
these files on a BSD 4.2 UNIX system, I got a core dump.  The problem was
being caused by high-bits set in the filename field inside the squeezed file.
The contents of this field are read during unsqueezing, and determine the
filename under which the unsqueezed file will be stored.  When UNIX tried to
create files having high-bits set in the filename, it really "lost it".  Here
is Keith's reply to my message:


----- Forwarded message # 1:

Date: Mon, 4 Aug 1986  22:04 MDT
From: Keith Petersen <W8SDZ@SIMTEL20.ARPA>
To:   David Towson (SECAD) <towson@AMSAA.ARPA>
Subject: Bad files in <CPM.TURBODOS-SIGI>

Dave, the UnSQueezer program is supposed to strip off the high order
bits of the filenames in case they had any CP/M attributes set when
they were LBR'ed.  This was added to the specification for USQ some
time ago after some SysOps started using attributes inside LBRs for
certain controls over privacy and downloading by callers.

--Keith

----- End of forwarded messages

     The unsqueezer I have been using is from <UNIX.CPM>XUSQ107.C in the
SIMTEL20 <UNIX> archive.  A look at the source code reveals that the high-
bits of the filename characters are indeed not being stripped.  The fix is
very simple.  Here it is:

	p = origname;				/* Get original file name */
	do {					/* send it to array */
		*p = getc(in);
		*p &= 0177;    <---------------- ADD THIS LINE
	} while(*p++ != '\0');


The new line goes after line number 136 (at least in my copy).

     I don't know whether a similar change would be desirable for XTYPE107.C
and/or XSQ107.C as I haven't looked.  If you would like to know whether the
unsqueezer you are using can handle filenames having CP/M attribute (high)
bits set, grab a copy of <CPM.TURBODOS-SIGI>DPINST.MQC from SIMTEL20 and try
to unsqueeze it.

     Thanks for your help, Keith.



Dave