wong@cs.UAlberta.CA (Brian Wong) (03/15/91)
Hi, I just download pd1:<msdos.sysutl>vram386.zip from SIMTEL20. I cannot unpack it using pkunzip. The file seems to be corrupted. I download the file from another site and it has the same problem. Can whoever is in charge look into this? Thanks.
w8sdz@rigel.acs.oakland.edu (Keith Petersen) (03/16/91)
wong@cs.UAlberta.CA (Brian Wong) writes: >I just download pd1:<msdos.sysutl>vram386.zip from SIMTEL20. >I cannot unpack it using pkunzip. >The file seems to be corrupted. >I download the file from another site and it has the same problem. >Can whoever is in charge look into this? Ok. SIMTEL20> unzip -t vram386 Testing: CHKMEM.EXE OK Testing: HRAM.EXE OK Testing: HRAM1.DOC OK Testing: HRAMDEV.SYS OK Testing: READ.ME OK Testing: VRAM386A.DOC OK Testing: VRAM386.SYS OK Testing: VRAM386.DOC OK Testing: HRAM.SYS OK No problem there. Must be your FTP was in the wrong mode, or you downloaded with Kermit and forgot to tell your host's Kermit to use binary mode. Keith -- Keith Petersen Maintainer of SIMTEL20's MSDOS, MISC & CP/M archives [IP address 26.2.0.74] Internet: w8sdz@WSMR-SIMTEL20.Army.Mil or w8sdz@vela.acs.oakland.edu Uucp: uunet!umich!vela!w8sdz BITNET: w8sdz@OAKLAND
wong@cs.UAlberta.CA (Brian Wong) (03/16/91)
w8sdz@rigel.acs.oakland.edu (Keith Petersen) writes: >>I just download pd1:<msdos.sysutl>vram386.zip from SIMTEL20. >>I cannot unpack it using pkunzip. >>The file seems to be corrupted. >>I download the file from another site and it has the same problem. >>Can whoever is in charge look into this? >SIMTEL20> unzip -t vram386 . . . >Testing: VRAM386.DOC OK >Testing: HRAM.SYS OK >No problem there. Must be your FTP was in the wrong mode, or you >downloaded with Kermit and forgot to tell your host's Kermit to use >binary mode. >Keith Petersen >Maintainer of SIMTEL20's MSDOS, MISC & CP/M archives [IP address 26.2.0.74] This is how I download vram386.zip: 1. ftp it from 26.2.0.74. yes I DID use tenex mode. the second time I tried 128.252.135.4 and I used binary mode. 2. uuencode the file, get a file called vram386.uue 3. use 1k-xmodem program to download the text file to my pc 4. uudecode the file then pkunzip I have download several files before and there is no problem. When I tried to decode vram386.uue, it gave an error message: End of file encountered. enter name of another uue file. I check vram386.uue and there are the 'begin' and 'end' statements and it looks OK. I guessed I incorrectly jump to the conclusion that the original zip file is corrupted. What have I done wrong here? How come the procedure works for many other files but not vram??
wong@cs.UAlberta.CA (Brian Wong) (03/16/91)
wong@cs.UAlberta.CA (Brian Wong) writes: >This is how I download vram386.zip: >1. ftp it from 26.2.0.74. yes I DID use tenex mode. > the second time I tried 128.252.135.4 and I used binary mode. >2. uuencode the file, get a file called vram386.uue >3. use 1k-xmodem program to download the text file to my pc >4. uudecode the file then pkunzip >I have download several files before and there is no problem. >When I tried to decode vram386.uue, it gave an error message: >End of file encountered. enter name of another uue file. >I check vram386.uue and there are the 'begin' and 'end' statements and it >looks OK. >I guessed I incorrectly jump to the conclusion that the original >zip file is corrupted. >What have I done wrong here? >How come the procedure works for many other files but not vram?? I use the same procedure on 128.214.12.37 and the file can be downloaded correctly. Still don't know why it didn't work for the other two sites. Thanks a lot.
kmorrill@brahms.udel.edu (Ken Morrill) (03/16/91)
In article <wong.669112367@scapa>, wong@cs.UAlberta.CA (Brian Wong) writes: > This is how I download vram386.zip: > 1. ftp it from 26.2.0.74. yes I DID use tenex mode. > the second time I tried 128.252.135.4 and I used binary mode. > 2. uuencode the file, get a file called vram386.uue > 3. use 1k-xmodem program to download the text file to my pc > 4. uudecode the file then pkunzip What puzzles me about your general procedure (which I understand almost always _works_) is why you take the time to turn zipped files that you want zipped anyway into text files at all before downloading to your pc. Am I missing something? Is there some advantage to doing what Brian describes above as his normal procedure for bringing files to his pc? -- ============================================================== Kenneth J. Morrill <kmorrill@brahms.udel.edu> (302) 737-5528 ==============================================================
valley@uchicago (Doug Dougherty) (03/17/91)
wong@cs.UAlberta.CA (Brian Wong) writes: >1. ftp it from 26.2.0.74. yes I DID use tenex mode. > the second time I tried 128.252.135.4 and I used binary mode. >2. uuencode the file, get a file called vram386.uue >3. use 1k-xmodem program to download the text file to my pc >4. uudecode the file then pkunzip First of all, truer words have never been spoken than the statement/position that when people have problems with files d/l'd from cbib or Simtel and assert that the file on the d/l server must therefore be corrupt, those people are wrong (or, shall we say, they are wrong at least 99.999999% of the time...) That said, I should point out that the same claim cannot be made for the unmoderated groups, where there is no control over how people u/l stuff. Second, why did you do the uuencode/uudecode pair? Why not just d/l the .ZIP file to your PC in binary mode, using any of the popular protocols? (Xmodem-1K should certainly work) By doing that, you have broken the integrity of the original file, and are, therefore, on your own... (Sorry for the nasty sound of this, but this is really an area where the doctrine of KISS applies.)
otto@kipuna.jyu.fi (Otto J. Makela) (03/17/91)
In article <19705@brahms.udel.edu> kmorrill@brahms.udel.edu (Ken Morrill) writes: In article <wong.669112367@scapa>, wong@cs.UAlberta.CA (Brian Wong) writes: > This is how I download vram386.zip: > 1. ftp it from 26.2.0.74. yes I DID use tenex mode. > the second time I tried 128.252.135.4 and I used binary mode. > 2. uuencode the file, get a file called vram386.uue > 3. use 1k-xmodem program to download the text file to my pc > 4. uudecode the file then pkunzip What puzzles me about your general procedure (which I understand almost always _works_) is why you take the time to turn zipped files that you want zipped anyway into text files at all before downloading to your pc. Neither do I understand the uuencoding step: xmodem-1k requires a full 8-bit path for the transfer anyway, why try to textify it first ? -- /* * * Otto J. Makela <otto@jyu.fi> * * * * * * * * * * * * * * * * * * */ /* Phone: +358 41 613 847, BBS: +358 41 211 562 (USR HST/V.32, 24h/d) */ /* Mail: Kauppakatu 1 B 18, SF-40100 Jyvaskyla, Finland, EUROPE */ /* * * Computers Rule 01001111 01001011 * * * * * * * * * * * * * * * * */
mcastle@mcs213e.cs.umr.edu (Mike Castle {Nexus}) (03/17/91)
In article <wong.669117529@scapa> wong@cs.UAlberta.CA (Brian Wong) writes: >wong@cs.UAlberta.CA (Brian Wong) writes: >>This is how I download vram386.zip: >>1. ftp it from 26.2.0.74. yes I DID use tenex mode. >> the second time I tried 128.252.135.4 and I used binary mode. >>2. uuencode the file, get a file called vram386.uue >>3. use 1k-xmodem program to download the text file to my pc >>4. uudecode the file then pkunzip Perhaps the versions or uuen/uudecode are not completely compatible? Check to see if your uuencode uses ` instead of spaces. It may be that when you download, xmodem is stipping trailing blanks, or deleting blanks lines. I suppose you should check your settings on xmodem as well. As to why anyone would want to uuencode a file before downloading, I would like to mention that this is how I download 99.9% of my stuff. The system I use to do most of my downloading ONLY supports kermit. The main connection I use is goes through 8-7-8 bit connections. When I download in binary format, those conversions take some considerable overhead. I can download a uuencoded file in text format faster than I can download the corresponding text file. This same connection, when using zmodem to download from this unix system, only text files can be downloaded. Binary files with zmodem are right out. There are reasons for downloading using this method. -- Mike Castle (Nexus) S087891@UMRVMA.UMR.EDU (preferred) | XEDIT: Emacs mcastle@mcs213k.cs.umr.edu (unix mail-YEACH!)| on a REAL Life is like a clock: You can work constantly, and be right | operating all the time, or not work at all, and be right twice a day. | system. :->
mcastle@mcs213e.cs.umr.edu (Mike Castle {Nexus}) (03/17/91)
In article <2420@umriscc.isc.umr.edu> mcastle@mcs213e.cs.umr.edu (Mike Castle {Nexus}) writes: >conversions take some considerable overhead. I can download a uuencoded file >in text format faster than I can download the corresponding text file. This ^^^^ That should say 'corresponding binary file' -- Mike Castle (Nexus) S087891@UMRVMA.UMR.EDU (preferred) | XEDIT: Emacs mcastle@mcs213k.cs.umr.edu (unix mail-YEACH!)| on a REAL Life is like a clock: You can work constantly, and be right | operating all the time, or not work at all, and be right twice a day. | system. :->
wong@cs.UAlberta.CA (Brian Wong) (03/17/91)
Hi,
So far nobody can tell me why my procedure:
ftp - uuencode - transfer - uudecode - pkunzip
WORKS for vram386.zip from 128.214.12.37
but fails for the same(??) file from simtel20 and 128.252.135.4.
I use the above procedure for many other programs and it has not
failed.
A lot of people said I must be doing something wrong and criticized
on my uuencode-uudecode cycle.
I am 100% sure I was using the right mode during ftp.
i.e. tenex with simtel and binary with 128.214 and 128.252.
I uuencode the file first because transfering in binary mode
has given me some problems before on MY machine.
I use: xmodem sbk file.zip and it fails 2 out of 3 times so
I quit using binary transfer.
Anyway, sorry for wasting so much bandwidth and thanks
to all those who are so willing to help.
P.S. The size of the file I ftp from 128.252 is 62644
but the one I got from 128.214 is 62904.klf1305@chensun1.tamu.edu (Kelly L. Fergason) (03/17/91)
In article <wong.669178528@scapa> wong@cs.UAlberta.CA (Brian Wong) writes: > > > >Hi, > >So far nobody can tell me why my procedure: >ftp - uuencode - transfer - uudecode - pkunzip >WORKS for vram386.zip from 128.214.12.37 >but fails for the same(??) file from simtel20 and 128.252.135.4. >I use the above procedure for many other programs and it has not >failed. Well, I don't know about anyone else on the net, but for me, every once in a while, things just don't work. By this, I mean that you do everything right, but the results just are not correct. In my experience, it seems to be the ftp part of the procedure. I usually just attribute it to gremlins in the lines, and do it again, and it usually works. Kelly Fergason