AGRDEN@latvax8.lat.oz (07/12/90)
Could someone please post Shrinkit GS to Comp.Binaries.apple2 Thanks
mrharrison@lion.waterloo.edu (Mike Harrison) (07/18/90)
Could someone please post parts 4 and 5 of Shrinkit GS on comp.binaries.apple2? They didn't make it to our site. Thanks Mike -- Mike Harrison | "...because they drink a lot in Hamburg, and at mrharrison@lion.uwaterloo.ca | night, you can skate home in other people's mrharrison@tiger.uwaterloo.ca| sick." -- Dieter, SNL (Why I Like Hamburg)
shawn@marilyn.UUCP (Shawn P. Stanley) (07/31/90)
When ShrinkIt GS appeared on comp.binaries.apple2, I only saw part 2 of 5.
I'm not sure what caused the others to escape my system. Could someone
re-post ShrinkIt GS (the latest version)? Thanks!
--
Shawn P. Stanley shawn@marilyn.marilyn.mn.org
bungia!marilyn!shawn {rosevax,crash}!orbit!marilyn!shawnsandvig@poincare.geom.umn.edu (Cary &) (08/09/90)
ok.. if these problems have already been pointed out, I'm sorry... if not could
someone make sure this gets to the author...
problems I've discovered using Shrinkit GS:
* there is an error in the coding of the uncompress routines that causes it
to incorrectly report a corrupted archive when unpacking large files or
disks that were very full
* there is a user interface design flaw in the delete dialog... delete
should not be the default option, or if a folder is selected for delete
the user should be propted for confirmation... this flaw enabled me to
accidentally delete nearly 7 Meg of archives
* there is a possible error in the delete routines themselves.. this is
related to the above problem... when I exited Shrinkit GS to exhume my
files I discovered, much to my disapointment, that they were in some way
deleted incorrectly... and, thus, none of them could be recovered... the
error lies somewhere in the code to flip the halfs of the key blocks...
Other information:
just in case these errors are not universal this is my system configuration:
* Apple IIgs - ROM 3
* 3.125 Meg Ram
* 209Meg SCSI HD (6 32Meg partitions, the rest in the 7th)
* Apple HS SCSI DMA controler
nothing else attached to my system should be effecting this...
--
-Cary
(.sig pending)bkahn@archive.rtp.dg.com (Bruce Kahn) (08/09/90)
In article <SANDVIG.90Aug8152250@poincare.geom.umn.edu>, sandvig@poincare.geom.umn.edu (Cary &) writes: |> [...] |> problems I've discovered using Shrinkit GS: |> |> * there is an error in the coding of the uncompress routines that causes it |> to incorrectly report a corrupted archive when unpacking large files or |> disks that were very full |> Could you pls explain the details of this a bit further. What do you mean by 'large files' or 'very full'. Can you tell me what you were unpacking or the size of the files/disks? Andy cant be expected to fix something w/o having a better idea of what may be wrong or where to start... |> * there is a user interface design flaw in the delete dialog... delete |> should not be the default option, or if a folder is selected for delete |> the user should be propted for confirmation... this flaw enabled me to |> accidentally delete nearly 7 Meg of archives |> Ill pass this along. I could be wrong but I dont recall any exact requirements on what defaults to use for the delete screen. Some programs Ive seen have 'Delete' as the default, others have 'Dont Delete'. Ill poke around the HIG some more... |> * there is a possible error in the delete routines themselves.. this is |> related to the above problem... when I exited Shrinkit GS to exhume my |> files I discovered, much to my disapointment, that they were in some way |> deleted incorrectly... and, thus, none of them could be recovered... the |> error lies somewhere in the code to flip the halfs of the key blocks... What did you use to try and recover the deleted files? What happened when you tried to recover the data? Keep in mind that if you did any writes to the disks between deletes then you may not be able to recover the deleted files! |> |> Other information: |> |> just in case these errors are not universal this is my system configuration: |> * Apple IIgs - ROM 3 |> * 3.125 Meg Ram |> * 209Meg SCSI HD (6 32Meg partitions, the rest in the 7th) |> * Apple HS SCSI DMA controler |> |> nothing else attached to my system should be effecting this... |> -- |> |> -Cary |> (.sig pending) If you can post some more information Ill relay it to Andy and post any responses I get... Bruce (bkahn@archive.rtp.dg.com)
shrinkit@pro-novapple.cts.com (Andy Nicholas) (08/13/90)
> * there is an error in the coding of the uncompress routines that causes it > to incorrectly report a corrupted archive when unpacking large files or > disks that were very full I often have fits about messages like this mainly because there isn't enough information here to get a handle on what's going wrong. It would be better for you to mail me an archive on which this happens, or better yet, do what dennis doms did when we were bug hunting at KC and build me a system disk that causes the error or always happen, put both the system disk and the archive which makes it go boom in the mail and mail it to me with an explanation. Stuff like this makes it next to impossible to try to fix something. If you want to gripe, fine, but at least try to help me fix it! :-) > * there is a user interface design flaw in the delete dialog... delete > should not be the default option, or if a folder is selected for delete > the user should be propted for confirmation... this flaw enabled me to > accidentally delete nearly 7 Meg of archives Well, maybe. Some of the guys at Apple DTS (I won't name names) think that the UI in the delete dialog is fine. Others (I have heard) in DTS don't feel that the delete dialog is a good thing. I felt it was kind of straightforward and honest. Clicking "delete" does exactly that. I can't hold your hand via the dialogs every step of the way -- to a certain extent I do also use GSHK and often try to streamline the way it's put together. (ie, I don't like excess dialogs). > there is a possible error in the delete routines themselves.. this is > related to the above problem... when I exited Shrinkit GS to exhume my > files I discovered, much to my disapointment, that they were in some way > deleted incorrectly... and, thus, none of them could be recovered... the > error lies somewhere in the code to flip the halfs of the key blocks... I don't do the deleting, GSOS does. If there's a problem, I suspect it lies someplace either in the OS or what you expect of the OS. GSHK just uses the class 1 _Destroy call. ---- I'll be using this account about once a week. please don't email me anything huge (like large archives... use the usmail) as I won't be on that often. andy shrinkit@pro-novapple.cts.com PROLINE: pro-novapple!shrinkit UUCP: crash!pro-novapple!shrinkit ARPA: crash!pro-novapple!shrinkit@nosc.mil INET: shrinkit@pro-novapple.cts.com
bsherman@mthvax.cs.miami.edu (Bob Sherman) (08/15/90)
Welcome back to the net Andy.. Good to see you back online, even if only once a week.. -- bsherman@mthvax.cs.miami.edu | bsherman@pro-exchange | MCI MAIL:BSHERMAN
r.levy@cooper.cooper.EDU (Rami Levy ) (09/25/90)
Can anyone tell me where I can download a copy of ShrinkIt GS from? (Or even a more recent version of ShrinkIt than 3.0.1?) Thanks in advance. Rami please respond to: r.levy@marvin.cooper.edu or levy@coopervax.cooper.edu