awillis@pro-angmar.UUCP (Albert Willis) (04/29/89)
Is anyone else having a problem with ShrinkIt 2.01 not being able to extract all the files from a Binary II file? I recently tried to extract 75 files from a Binary II file, and ShrinkIt stopped at file #30. This happens when ever a Binary II file has more than 30-40 files. Is this a bug, or am I missing something? Albert Willis INET awillis@pro-angmar.cts.com UUCP pro-angmar!awillis@obsolete.uucp ProLine ..pro-carolina!pro-angmar!awillis AppleLink PE BCS Al
matthew@sunpix.UUCP ( Sun NCAA) (05/01/89)
In article <8904290459.AA02590@obsolete.UUCP>, Albert Willis writes:
[comments about ShrinkIt 2.01 Binary II unpacking bug deleted]
I've seen notes about this problem on one of these networks I read (I sometime
confuse what I read and which network I read it on). Yes, the problem is know.
I believe the work around is to just press return and it will keep on going (I
had it happen to me one (35 articles in the Binary II file), and thats all I did).
--
Matthew Lee Stier |
Sun Microsystems --- RTP, NC 27709-3447 | "Wisconsin Escapee"
uucp: { sun, mcnc!rti }!sunpix!matthew |
phone: (919) 469-8300 fax: (919) 460-8355 |nakada@husc4.HARVARD.EDU (Paul Nakada) (05/02/89)
while we're on the subject.. do iishrink and iiunshrink work on
apple][+ computers? I have tested both on my //c and they both work
fine. I've heard from a few people concerning problems running them on
a ][+ ... can those people with ][+ computers please test them?
thanks..
-paul nakada
__
| Paul Nakada '89 #8-) |
North House | nakada@husc4.HARVARD.EDU
Harvard College | seismo>!harvard!husc4!nakada.UUCP
Cambridge, MA 02138 | rutgers/ nakada@husc4.BITNET
617/498-6255 || 6264 | __|nicholaA@moravian.EDU (05/03/89)
>while we're on the subject.. do iishrink and iiunshrink work on >apple][+ computers? I have tested both on my //c and they both work >fine. I've heard from a few people concerning problems running them on >a ][+ ... can those people with ][+ computers please test them? >thanks.. V1.3 of the II+ versions should work fine. I'd like to publicly thank Michael Ziober who helped me *ALOT* in tracking down the problems with those programs... Thanks Michael! :-) >-paul nakada andy nicholas ---- Andy Nicholas CsNET: shrinkit@moravian.edu Box 435 InterNET: shrinkit%moravian.edu@relay.cs.net Moravian College uucp: rutgers!lafcol!lehi3b15!mc70!shrinkit Bethlehem, PA 18018 GEnie: shrinkit ---- AppleLink PE: shrinkit
Kreme@cup.portal.com (Lewis Kreme Butler) (05/03/89)
I've actually have several problems with Shrinkit 2.01...
1) If you copy a file and there is not enough room to copy the file
fully, there is no warning signal from Shrinkit. It just doesn't
complete the copy.
2) If the file type is not $E{any character} the file will not be recognized
as a NFuX file. I have to use Copy ][+ or Block Warden to edit the file
type byte to $E0 from $04 (TXT), since most times a BBS sends a file as
E0 type.
3) The documentation is just Shrinkit 1.0 with addtions at the end, instead
of a comprehensive Doc file.
The last is a minor point, but the first two are pretty serious.
------------------------------------------------------------------------------
| | You're all coffee drinkers, no tea for |
| kreme@cup.portal.com | you! -- Isstvan |
------------------------------------------------------------------------------
| DISCLAIMER: All comments are the responsibility of a small purple man from |
| the area of Rilos. Keep that in mind when considering flames. |
------------------------------------------------------------------------------matthew@sunpix.UUCP ( Sun Visualization Products) (05/05/89)
In article <17856@cup.portal.com>, Lewis Kreme Butler writes: | I've actually have several problems with Shrinkit 2.01... | | 1) If you copy a file and there is not enough room to copy the file | fully, there is no warning signal from Shrinkit. It just doesn't | complete the copy. It also has an additional problem of informing you that it has deleted a file it was instructed to, when in fact it has not (i.e.: delete a directory that has something in it, or delete a file on a write protected diskette) | 2) If the file type is not $E{any character} the file will not be recognized | as a NFuX file. I have to use Copy ][+ or Block Warden to edit the file | type byte to $E0 from $04 (TXT), since most times a BBS sends a file as | E0 type. Could it be, that that the BBS you are using, and your software is transferring the file in ProDOS xmodem mode. If it is, and the Aux FileType is not being transferred corretly, your probably going to have this problem. (If you do a catalog, and the filetype is $E0, and the aux_filetype is not $8002, that may be your problem.) | 3) The documentation is just Shrinkit 1.0 with addtions at the end, instead | of a comprehensive Doc file. True, the docs could be better, but at least there is readable docs. | The last is a minor point, but the first two are pretty serious. | | ------------------------------------------------------------------------------ | | | You're all coffee drinkers, no tea for | | | kreme@cup.portal.com | you! -- Isstvan | | ------------------------------------------------------------------------------ | | DISCLAIMER: All comments are the responsibility of a small purple man from | | | the area of Rilos. Keep that in mind when considering flames. | | ------------------------------------------------------------------------------ -- Matthew Lee Stier | Sun Microsystems --- RTP, NC 27709-3447 | "Wisconsin Escapee" uucp: { sun, mcnc!rti }!sunpix!matthew | phone: (919) 469-8300 fax: (919) 460-8355 |
djhill@rodan.acs.syr.edu ( Number_6 **) (05/05/89)
I too have had a problem with Shrinkit although it's a different one. When either adding files to an archive or simply Shrinking files into a new archive, if you run out of disk space the entire archive is effectively trashed since you lose many of the files in the archive. For example, an archive that have over 40 records in it was reduced to five records although it was still 1300 blocks long. ----------------------------------------------------------------------------- Douglas J. Hill "I will not be pushed, filed, stamped, djhill@rodan.acs.syr.edu indexed, briefed, de-briefed or numbered! RSDJH @ SUVM (BITNET) ...My life is my own."
nicholaA@moravian.EDU (05/08/89)
>1) If you copy a file and there is not enough room to copy the file > fully, there is no warning signal from Shrinkit. It just doesn't > complete the copy. This is true. There are a number of prompts within shrinkit which need to be changed. Off the top of my head -- if you try to unpack 1 archive, and it's not a NuFX archive, shrinkit will beep 3 times and say "finished" when it never processed anything. These will be fixed in a future revision when I have time to do it. I _am_ aware that some of the missing/erroneous prompts exist, and _am_ listening... :-) >2) If the file type is not $E{any character} the file will not be recognized > as a NFuX file. I have to use Copy ][+ or Block Warden to edit the file > type byte to $E0 from $04 (TXT), since most times a BBS sends a file as > $E0 type. Uh, No. ShrinkIT will attempt to unpack any archive that you tell it to, regardless of filetype. If the archive is not a NuFX archive (which shrinkit does NOT need the filetype information to check), then you will be told that shrinkit can't handle that particular archive and be allowe to keep processing the other files selected. I believe this is documented in the 2.01 and 2.02 docs. Please (re)read them throughly. >3) The documentation is just Shrinkit 1.0 with additions at the end, instead > of a comprehensive Doc file. Uh, No. (Honest, I'm not trying to act like a smart-aleck :-) Actually, the additions were adding to the _beginning_ of the docs. As most people who know what I'm working on will attest, I have very little time to work on docs... no one has ever offered to clean up the docs for 1.0 and completely incorporate 2.0's features, so that will probably be left unattended. (Those of you who know me will also attest to the fact that I write lousy end-user documentation, too... :-) >kreme@cup.portal.com andy ---- Andy Nicholas CsNET: shrinkit@moravian.edu Box 435 InterNET: shrinkit%moravian.edu@relay.cs.net Moravian College uucp: rutgers!lafcol!lehi3b15!mc70!shrinkit Bethlehem, PA 18018 GEnie: shrinkit ---- AppleLink PE: shrinkit
nicholaA@moravian.EDU (05/08/89)
>I too have had a problem with Shrinkit although it's a different one. When >either adding files to an archive or simply Shrinking files into a new >archive, if you run out of disk space the entire archive is effectively >trashed since you lose many of the files in the archive. For example, an >archive that have over 40 records in it was reduced to five records although >it was still 1300 blocks long. v2.01 and v2.02 should no longer have that problem. The bug you describe existed up into v1.1, but quite honestly, it really _should_ work, because the same situation happened to me a week ago and everything was fine... >Douglas J. Hill > djhill@rodan.acs.syr.edu andy ---- Andy Nicholas CsNET: shrinkit@moravian.edu Box 435 InterNET: shrinkit%moravian.edu@relay.cs.net Moravian College uucp: rutgers!lafcol!lehi3b15!mc70!shrinkit Bethlehem, PA 18018 GEnie: shrinkit ---- AppleLink PE: shrinkit