mike@captain.UUCP (Mike Proicou) (07/04/89)
In article <785@bagend.UUCP> jan@bagend.UUCP (Jan Isley) writes: > >-rw-r--r-- 1 jan users 3328 Jul 3 00:01 README >-rw-r--r-- 1 jan users 7022592 Jul 3 00:22 s4diag >-rw-r--r-- 1 jan users 82737 Jul 3 00:07 s4diag.Z >-rw-r--r-- 1 jan users 115772 Jul 3 00:06 s4diag.Z.uue >-rw-r--r-- 1 jan users 55081 Jul 3 00:02 s4diag.Z.uue.1 >-rw-r--r-- 1 jan users 60691 Jul 3 00:02 s4diag.Z.uue.2 > >I think I'll stick with my version of s4diag! Anyone else EVER see >uncompress do this? > >unix-pc rev G, release 3.51, 3.5 MB memory, P5.1 and WD2010, ST4096 drive. > I've seen uncompress act up many times on .Z files that get corrupted. My favorite is forgetting binary mode in Kermit or ftp. The file is pretty much guaranteed to be more than 5 Meg if you let it finish! Here's the sizes I get: total 401 -rw-r--r-- 1 mike users 2084 Jul 3 19:50 Install -rw-r--r-- 1 mike users 3328 Jul 3 19:50 README -rwxr-xr-x 1 mike users 82673 Jul 3 19:51 s4diag.Z* ^^^ -rw-r--r-- 1 mike users 55081 Jul 3 19:50 s4diag.Z.uue.1 -rw-r--r-- 1 mike users 60691 Jul 3 19:50 s4diag.Z.uue.2 And the result after uncompress is: -rwxr-xr-x 1 mike users 150478 Jul 3 19:51 s4diag* Your s4diag.Z file is corrupted. Mike -- Mike Proicou | The supreme irony of life is mproicou@blackbird.afit.af.mil | that hardly anyone gets out osu-cis!n8emr!captain!mike | of it alive. -- R Heinlein
thad@cup.portal.com (Thad P Floryan) (07/04/89)
Re: Jan Isley's comments re: uncompress re: the s4diag I recently posted ...
I don't know what to say. I experienced similar problems myself the first
time I unpacked some GNU distribution from osu-cis using their published
instructions regarding using "zcat" (linked to uncompress). I checked the
posting twice before sending it out to the world, and when using the three
lines of instructions (following) all worked fine:
$ cat s4diag.Z.uue.1 s4diag.Z.uue.2 > s4diag.Z.uue
$ uudecode s4diag.Z.uue
$ uncompress s4diag
I even uncompressed it fine on an HPUX, an Amdahl, and an Amiga.
If the compress you're using is the old one from the STORE!, that may explain
the problem; the uu{en|de}code, compress and shar I used are fairly recent
ones from the net. In fact, the {un}compress is the one I got from osu-cis
(for use on the UNIXPC), the compress on the HPUX is whatever accompanied
HPUX, same for the Amdahl, and the compress on the Amiga is from a PD Amiga
software collection; all of these are compatible in the 16-bit mode and all
process files created by the others.
Thad Floryan [ thad@cup.portal.com (OR) ..!sun!portal!cup.portal.com!thad ]jan@bagend.UUCP (Jan Isley) (08/08/89)
Well, I have the advanced diagnostics anyway but I thought I would play with what was posted and everything is going fine until I ran uncompress. It was running in the background while I edited something and after a few minutes, I'm thinking it should be done by now but I still hear the disk chugging away. A ps reveals uncompress still running and taking up a lot of time: PID TTY TIME COMMAND 12218 w1 3:35 uncompre About that time the notorious "no space left on device" appears, ls reveals: -rw-r--r-- 1 jan users 2084 Jul 3 00:02 Install -rw-r--r-- 1 jan users 3328 Jul 3 00:01 README -rw-r--r-- 1 jan users 7022592 Jul 3 00:22 s4diag -rw-r--r-- 1 jan users 82737 Jul 3 00:07 s4diag.Z -rw-r--r-- 1 jan users 115772 Jul 3 00:06 s4diag.Z.uue -rw-r--r-- 1 jan users 55081 Jul 3 00:02 s4diag.Z.uue.1 -rw-r--r-- 1 jan users 60691 Jul 3 00:02 s4diag.Z.uue.2 I killed the process, took about 2 minutes to give me a prompt back. 0 blocks 8598 i-nodes I think I'll stick with my version of s4diag! Anyone else EVER see uncompress do this? unix-pc rev G, release 3.51, 3.5 MB memory, P5.1 and WD2010, ST4096 drive. Jan Isley, follower of Zen, picker of nit jan@bagend | gatech!bagend!jan | (404) 434-1335
res@cbnews.ATT.COM (Robert E. Stampfli) (08/15/89)
In article <785@bagend.UUCP> someone writes: > > PID TTY TIME COMMAND > 12218 w1 3:35 uncompre > >About that time the notorious "no space left on device" appears, ls reveals: > >-rw-r--r-- 1 jan users 7022592 Jul 3 00:22 s4diag I have heard several people allude to compress doing this to them, and I frankly lay no claims as to knowing why. But, I can't understand why people allow this to happen in the first place. There is a shell built-in called "ulimit" which will prevent files from growing past a certain size. My system is set to limit files to 1 meg and this has never caused any trouble. I do this in the /etc/profile (ulimit 2048). If there is a reason to deal with larger files this can be circumvented. It seems like this simple step would save a lot of hassles. Rob Stampfli att!cbnews!res (work) osu-cis!n8emr!kd8wk!res (home)
thad@cup.portal.com (Thad P Floryan) (08/15/89)
Re: Jan Isley's problem uncompressing the s4diag: Someone else posted identical symptoms about 3 or 4 weeks ago (shortly after I posted the enhanced s4diag). The problem was easily detected to be a corrupted transfer: the SIZE of the uue files was wrong. Seems "compress" will do this, and run free diskspace down to zero in its attempt to uncompress the corrupted archive. Most sites, even in Europe, received the s4diag correctly. If you need a correct copy, send email. Thad Floryan [ thad@cup.portal.com (OR) ..!sun!portal!cup.portal.com!thad ]
ebh@argon.UUCP (Ed Horch) (08/16/89)
In article <8991@cbnews.ATT.COM> res@cbnews.ATT.COM (Robert E. Stampfli) writes: >In article <785@bagend.UUCP> someone writes: >>[about trying to uncompress the new s4diag file and having it grow >>until ulimit is hit or the file system runs out of space, or something >>equally antisocial] > >I have heard several people allude to compress doing this to them, and I >frankly lay no claims as to knowing why. The most common cause of this is transferring a compressed file without setting your file transfer type to "binary" in whatever file transfer program you're using, e.g. Kermit or FTP, when said file transfer program defaults to seven-bit text. The result is a corrupted file, since the high bit of each byte is stripped off. This confuses compress's idea of what compressed bit patterns map to what plaintext strings. If you're not sure whether what you've got is clean or not, zcat the file and pipe it through "od -c". If the output looks like garbage, it probably is. GIGO. (Using "od -c" is a safe way of catting a file that might contain unknown control sequences.) -Ed
jcm@mtunb.ATT.COM (was-John McMillan) (08/16/89)
On the subject of the e.d. diskette: Every enhanced s4diag I've seen has been a copy of one I threw together a couple of years ago as a special item for someone-since-forgotten. Perhaps Thad's diskette is different: I'm always braced for surprises !-) Since that time -- in fact, only about a month ago -- data & E-mail from Craig Votava made me realize that my specifications for one of the drives is WRONG: Maxtor XT1140 ACTUALLY has: 918 Cylinders is LISTED as: 1024 Cylinders 1024 was the data I was provided at the time, and for unrecalled reasons I think I'd even called Maxtor to verify the data. On the OTHER SIDE: I believe the value of 1024 HAS BEEN SUCCESSFULLY USED -- but you wouldn't catch _ME_ risking it. If _I_ had an XT1140, I'd use "OTHER" to enter the details by hand. (Actually, I _DO_ have an XT1140... but it was hand-initialized by someone with the correct data.) john mcmillan -- att!mtunb!jcm -- GROWLING onwards...
jan@bagend.UUCP (Jan Isley) (08/18/89)
In article <8991@cbnews.ATT.COM> res@cbnews.ATT.COM (Robert E. Stampfli) writes: >In article <785@bagend.UUCP> someone writes: (it was me) >> >> PID TTY TIME COMMAND >> 12218 w1 3:35 uncompre >> >>About that time the notorious "no space left on device" appears, ls reveals: >>-rw-r--r-- 1 jan users 7022592 Jul 3 00:22 s4diag >... deleted ... But, I can't understand why people >allow this to happen in the first place. There is a shell built-in called >"ulimit" which will prevent files from growing past a certain size. > ... etc ... >It seems like this simple step would save a lot of hassles. Yes, it can save lots of hassles. Mine is usually set to 2048 also. I was, however, really curious to see just how far expire would run away with this. You would think that it would notice that the output was bigger than the input and stop. In this case, even after I ran out of disk space, expire kept on running. I could delete a file and expire would crank up again and the file would grow until it ran out of space again. Jan -- jan@bagend | gatech!bagend!jan | h (404)434-1335 | w (404)425-5700 Humankind cannot bear very much reality. T. S. Eliot