Path: utzoo!utgpu!news-server.csri.toronto.edu!clyde.concordia.ca!uunet!unsvax!jimi!howlin.cs.unlv.edu!maniac
From: maniac@howlin.cs.unlv.edu (Eric J. Schwertfeger)
Newsgroups: comp.sys.amiga
Subject: Re: Self Extracting Files (Re: PkaWare/PkaZip)
Message-ID: <1602@jimi.cs.unlv.edu>
Date: 13 Mar 90 19:03:04 GMT
References: <6984@ucdavis.ucdavis.edu> <90031103231016@masnet.uucp> <49220131.db93@edsel.engin.umich.edu> <23401@usc.edu>
Sender: news@jimi.cs.unlv.edu
Reply-To: maniac@howlin.cs.unlv.edu (Eric J. Schwertfeger)
Organization: UNLV Computer Science and Electrical Engineering
Lines: 17


	I'm glad that self-extracting archivers never caught on, but for 
a different reason.  The problem lies in the difference between transmitting 
an executable via modem, or a data file via modem.  I once spent several hours 
tring to unarchive a .PAK (the self-extracting kind) file, with no success 
because the uploader had managed to get the file incorrectly padded.  So, 
the file lengths wouldn't match, and AmiDos wouldn't execute the file.
	I tried padding the file more, chopping off some, but never could 
get the file to execute.  Since PAK doesn't have a non-self extracting 
option, I was stuck.  The way I finally got around it was to download the 
archiver, and add a 1K dummy file (shorter files didn't help) to the archive.  
Appearantly, this straightened out the problem.
	Actually, I have seen ONE good use for self-extracting archivers on a 
local BBS. The sysop keeps Zoo, ARC, LHArc, and Zippy in .PAK format so that
you can download them and use them even if you don't have any unarchivers.

Eric Schwertfeger, maniac@jimi.CS.UNLV.EDU