Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!cbatt!ihnp4!inuxc!pur-ee!uiucdcs!uxc.cso.uiuc.edu!hamilton
From: hamilton@uxc.cso.uiuc.edu.UUCP
Newsgroups: comp.sys.amiga
Subject: Re: ASDG Recoverable Ram Disk News
Message-ID: <172200029@uxc.cso.uiuc.edu>
Date: Wed, 28-Jan-87 14:45:00 EST
Article-I.D.: uxc.172200029
Posted: Wed Jan 28 14:45:00 1987
Date-Received: Fri, 30-Jan-87 05:30:44 EST
References: <2322@jade.BERKELEY.EDU>
Lines: 68
Nf-ID: #R:jade.BERKELEY.EDU:2322:uxc.cso.uiuc.edu:172200029:000:2613
Nf-From: uxc.cso.uiuc.edu!hamilton    Jan 28 13:45:00 1987


spencer@eris says:
>I was hoping to be the first to comment on this, but I am just too slow.
>Well, here is the official list of non-working programs to reach this node.
>
>Cleanramdisk            works
>Cleanramdisk.info       don't
>...etc...
>I used the same 
>uudecode on them all and moved them with one kermit file transfer.  And
>of course sh never complained about checksum errors.

    i had trouble downloading asdg.vdisk.device from the vax to my amiga.
i used c-kermit on the vax end, and i tried both vt100 and akermit on amy.
i made repeated efforts, making sure i had binary/image mode emabled on
both kermit's.  i always got complaint-free transfers, but the result was
always a munged file!  i don't know why kermit was failing, and it makes me
nervous about kermit in general.  ultimately, i noticed that the corruption
was starting at the same place in the file each time, so i used "dd" to chop
it at that point, downloaded the pieces seperately, and used "join" to
reconstruct.
   in the case of deleteramdisk, after the initial uudecode, the file
looked like:

	000003f3	hunk_header
	00000000	no name
	00000003	3 hunks,
	00000000 	numbered 0,
	00000002	thru 2
	00000340	1st hunk is x340 longwords (3,328 bytes)
	00007c00	2nd hunk is x7c00 longwords (126,976! bytes)
	00000100 	3rd junk is x100 longwords (1,024 bytes)
	0003e900	supposed to be 000003e9, hunk_code
	00034efa	supposed to be code hunk size
	032c436f	code
	...

after playing around with it, i think it was supposed to look like:

	000003f3	same as before
	00000000
	00000003
	00000000
	00000002
	0000030d	1st hunk is x30d longwords (3,124 bytes)
	0000004d	2nd hunk is x4d longwords (308 bytes)
	00000001	3rd hunk is x1 longwords (4 bytes)
	000003e9	hunk_code
	0000030d	x30d longwords
	4efa032c	code
	...

this passes as a valid "object module", but i haven't tried running
it to see if it really works.  it looks to me like the file was bad
BEFORE it was uuencoded; the .uu file looks fine, and part of the
problem is missing, not just modified, data.  thus, uu-checksums
would NOT have prevented it.  i haven't checked the icons yet, either.
    [at this point, i wonder why metacomco didn't include checksums
in their object module format...]
    in spite of the problems, i have it running on my amiga, and it's
saving me a lot of time every warm-boot.  thanx perry!

	wayne hamilton
	U of Il and US Army Corps of Engineers CERL
UUCP:	ihnp4!uiucuxc!hamilton
ARPA:	hamilton%uiucuxc@a.cs.uiuc.edu	USMail:	Box 476, Urbana, IL 61801
CSNET:	hamilton%uiucuxc@uiuc.csnet	Phone:	(217)333-8703
CIS:    [73047,544]			PLink: w hamilton