john@nereid.jpl.nasa.gov (John Veregge) (01/23/91)
1. Ftp fish disks from gatekeeper.dec.com to a Sun Sparc station. (The files are zoo format, that is *.zoo, in /pub/micro/amiga/fish.) 2. Format standard amiga floppy disk on the Sun with 'mkdfs -f'. (Format disk as a Sun Unix disk and then lay the MSDOS filesystem on top.) 3. Copy Unix files to amiga floppy with 'mcopy *.zoo a:' 4. Copy MSDOS file to Amiga with Dos2Dos. 5. Unarchive files with 'zoo -extract filename'. 6. Zoo begins unarchiving, but always exits prior to completion with 'CRC error, file probably corrupted'. (Zoo is version 2.0) With a straight text file (and the approprite command line switches) this download method works fine, leading me to guess that the problem is with zoo. Any and all help will be appreciated. Considering the bandwidth of the Amiga groups... email and I will summerize the correct responses. -- John R Veregge Section 348 - Flight Command and Data Jet Propulsion Laboratory Management (Technology Development) Calif Institute of Technology Mail stop: T1704, Office: T1704-P 4800 Oak Grove Drive Phone: (818) 354-0511, FAX: 393-4494 Pasadena, CA, USA 91109 john@triton.jpl.nasa.gov
ben@epmooch.UUCP (Rev. Ben A. Mesander) (01/24/91)
>In article <6060@mahendo.Jpl.Nasa.Gov> john@nereid.jpl.nasa.gov (John Veregge) writes: > >I recently built MTOOLS on the Sun Sparc Station 1, using the Sun supplied ~~~~~~~~~~~~ >compiler, in OS version 4.1.0. The only problem I had compiling was in the ~~~~~~~~ Urk. Did you try with the "optimizor" off? I've found it to be flaky. Also, you might look into the SunOS 4.1.1 upgrade, or GCC, if there is a Sparc version. >function formatit(), in file mkdfs.c, but the problem was in error reporting >only (Something had changed in the wait(2) function and/or it's data >structures.) and I just commented it out. Below is the commented out code. > >#if 0 > if ( WIFSIGNALED(w) ) { > fprintf(stderr,"%s: ",progname) ; > psignal(w.w_termsig,"/bin/fdformat") ; > if (w.w_coredump) > fprintf(stderr,"Core dumped\n") ; > exit(1) ; > } > > assert( WIFEXITED(w) ) ; /* If not signalled, must be exited > we are not tracing stopped processes */ >#endif > >Any other suggestions? > >-- >John R Veregge Section 348 - Flight Command and Data >Jet Propulsion Laboratory Management (Technology Development) >Calif Institute of Technology Mail stop: T1704, Office: T1704-P >4800 Oak Grove Drive Phone: (818) 354-0511, FAX: 393-4494 >Pasadena, CA, USA 91109 john@triton.jpl.nasa.gov -- | ben@epmooch.UUCP (Ben Mesander) | "Cash is more important than | | ben%servalan.UUCP@uokmax.ecn.uoknor.edu | your mother." - Al Shugart, | | !chinet!uokmax!servalan!epmooch!ben | CEO, Seagate Technologies |
john@nereid.jpl.nasa.gov (John Veregge) (01/25/91)
In article <6057@mahendo.Jpl.Nasa.Gov>, john@nereid.jpl.nasa.gov (John Veregge) writes: |> 1. Ftp fish disks from gatekeeper.dec.com to a Sun Sparc station. |> (The files are zoo format, that is *.zoo, in /pub/micro/amiga/fish.) |> 2. Format standard amiga floppy disk on the Sun with 'mkdfs -f'. |> (Format disk as a Sun Unix disk and then lay the MSDOS filesystem on top.) |> 3. Copy Unix files to amiga floppy with 'mcopy *.zoo a:' |> 4. Copy MSDOS file to Amiga with Dos2Dos. |> 5. Unarchive files with 'zoo -extract filename'. |> 6. Zoo begins unarchiving, but always exits prior to completion with |> 'CRC error, file probably corrupted'. (Zoo is version 2.0) |> |> With a straight text file (and the approprite command line switches) this |> download method works fine, leading me to guess that the problem is with zoo. |> So far all responses have suggested that I misused ftp (ascii vs binary). One soul was kind enough to mail me a copy of zoo to check (Phil Kernick). I didn't make that mistake (although paranoia required I use the zoo to verify what I already knew). Another suggestion was to check the disk in a MSDOS machine, however Dos2Dos reads MSDOS disks and had no problem recognizing the files. The problem is in MTOOLS. I was able to use the unix zoo in a simple test: zoo -test file -> mcopy file a: -> mcopy a:file . -> zoo -test file The file on return was corrupted. The file corruption occurred with both a disk formatted by Dos2Dos and a disk formatted by MTOOLS' mkdfs. Therefore the problem is probably in mcopy or something mcopy calls (mread or mwrite). I recently built MTOOLS on the Sun Sparc Station 1, using the Sun supplied compiler, in OS version 4.1.0. The only problem I had compiling was in the function formatit(), in file mkdfs.c, but the problem was in error reporting only (Something had changed in the wait(2) function and/or it's data structures.) and I just commented it out. Below is the commented out code. #if 0 if ( WIFSIGNALED(w) ) { fprintf(stderr,"%s: ",progname) ; psignal(w.w_termsig,"/bin/fdformat") ; if (w.w_coredump) fprintf(stderr,"Core dumped\n") ; exit(1) ; } assert( WIFEXITED(w) ) ; /* If not signalled, must be exited we are not tracing stopped processes */ #endif Any other suggestions? -- John R Veregge Section 348 - Flight Command and Data Jet Propulsion Laboratory Management (Technology Development) Calif Institute of Technology Mail stop: T1704, Office: T1704-P 4800 Oak Grove Drive Phone: (818) 354-0511, FAX: 393-4494 Pasadena, CA, USA 91109 john@triton.jpl.nasa.gov
john@nereid.jpl.nasa.gov (John Veregge) (01/25/91)
In article <6060@mahendo.Jpl.Nasa.Gov>, john@nereid.jpl.nasa.gov (John Veregge) writes: |> In article <6057@mahendo.Jpl.Nasa.Gov>, john@nereid.jpl.nasa.gov (John Veregge) writes: |> |> 1. Ftp fish disks from gatekeeper.dec.com to a Sun Sparc station. |> |> (The files are zoo format, that is *.zoo, in /pub/micro/amiga/fish.) |> |> 2. Format standard amiga floppy disk on the Sun with 'mkdfs -f'. |> |> (Format disk as a Sun Unix disk and then lay the MSDOS filesystem on top.) |> |> 3. Copy Unix files to amiga floppy with 'mcopy *.zoo a:' |> |> 4. Copy MSDOS file to Amiga with Dos2Dos. |> |> 5. Unarchive files with 'zoo -extract filename'. |> |> 6. Zoo begins unarchiving, but always exits prior to completion with |> |> 'CRC error, file probably corrupted'. (Zoo is version 2.0) |> |> |> |> With a straight text file (and the approprite command line switches) this |> |> download method works fine, leading me to guess that the problem is with zoo. |> |> |> |> So far all responses have suggested that I misused ftp (ascii vs binary). One |> soul was kind enough to mail me a copy of zoo to check (Phil Kernick). I didn't |> make that mistake (although paranoia required I use the zoo to verify what I |> already knew). Another suggestion was to check the disk in a MSDOS machine, |> however Dos2Dos reads MSDOS disks and had no problem recognizing the files. |> |> The problem is in MTOOLS. I was able to use the unix zoo in a simple test: |> zoo -test file -> mcopy file a: -> mcopy a:file . -> zoo -test file |> The file on return was corrupted. The file corruption occurred with both a |> disk formatted by Dos2Dos and a disk formatted by MTOOLS' mkdfs. Therefore |> the problem is probably in mcopy or something mcopy calls (mread or mwrite). |> |> I recently built MTOOLS on the Sun Sparc Station 1, using the Sun supplied |> compiler, in OS version 4.1.0. The only problem I had compiling was in the |> function formatit(), in file mkdfs.c, but the problem was in error reporting |> only (Something had changed in the wait(2) function and/or it's data |> structures.) and I just commented it out. Below is the commented out code. More Summary: I re-tested mcopy, this time using the standard high density floppy, and everything worked fine. Unfortunately my Amiga doesn't read high density floppies. Using an IBM as a go between (high density to low density floppy transfer) was a nice suggestion, but I don't have access to an IBM with more than a 5" drive. Using other protocols/archives won't work because I did not create the files I am attempting to transfer. I tried compiling without the optimization and on a Sun IPC with OS 4.1.1, all without success. Conclusions: The version of MTOOLS (1.6.2) that I have cannot correctly read/write files to low density 3.5" disks. The version of Dos2Dos (1.6) that I have cannot read high density 3.5" disks. (But, I believe their current version can.) Options: A) Find an IBM machine with a 3.5" drive. B) Fix the bug in MTOOLS or find a more current version. C) Buy the current version of Dos2Dos and a high density 3.5" drive. D) Pay for the Fish disks like the rest of the world. {-: Thanks for everyones help - this thread is dead! -- John R Veregge Section 348 - Flight Command and Data Jet Propulsion Laboratory Management (Technology Development) Calif Institute of Technology Mail stop: T1704, Office: T1704-P 4800 Oak Grove Drive Phone: (818) 354-0511, FAX: 393-4494 Pasadena, CA, USA 91109 john@triton.jpl.nasa.gov
saffe@lut.fi (Petri Savolainen) (01/29/91)
Funny, I had same kind of problems. Except that I transported from unix to Ms-dos machine, not Sun. Had same problems, though. Bad CRC. Yes, the problem was partly(?) that I had used ASCII-mode when getting files unix >>> ms-dos. For some strange reason ASCII-mode is default in our FTP when connec- ting to a MS-dos thingy. Anyway, I loaded a program with Bin-mode and it was O.K. I'm not sure, though, that this is the end of my problems, as it seems some others STILL gave bad CRC (I'm not sure if i used ASC/BIN). BTW, Why does my dos2dos crash when I try copying from ms-dos to ram to amigados? This is, if i do not use the same a-dos disk which i booted from to copy into. ... Another amiga kernel wonder? -Saffe- saffe@lut.fi P.S. Which is the newest version of Msh and where can I get it? The one on Fish 351/327 (?) is an old one and it's mountlist gives me "end of file before expected". AAARGGGH! I've been trying to install msh: for a week... I'm getting MAD!
xanthian@zorch.SF-Bay.ORG (Kent Paul Dolan) (01/29/91)
saffe@lut.fi (Petri Savolainen) writes:
BTW, Why does my dos2dos crash when I try copying from ms-dos to
ram to amigados? This is, if i do not use the same a-dos disk which
i booted from to copy into. ... Another amiga kernel wonder?
Sort of. Ram: doesn't have the structure of other Amiga file systems, so
if Dos2Dos is expecting sensible file system responses, and not getting
them, your writes to ram: could be going anywhere in memory, thus the crash.
Rad:, on the other hand, is a true Amiga file system, so try writing to there
if you want to go to memory, and see if that clears up your problem.
Kent, the man from xanth.
<xanthian@Zorch.SF-Bay.ORG> <xanthian@well.sf.ca.us>klute@tommy.informatik.uni-dortmund.de (Rainer Klute) (02/01/91)
In article <6062@mahendo.Jpl.Nasa.Gov>, john@nereid.jpl.nasa.gov (John Veregge) writes: |> Conclusions: |> The version of MTOOLS (1.6.2) that I have cannot correctly read/write |> files to |> low density 3.5" disks. The version of Dos2Dos (1.6) that I have cannot |> read |> high density 3.5" disks. (But, I believe their current version can.) Mtools 1.6.2 is out of date; the most recent version (as far as I know) is 2.0.3. I can exchange files between my SparcStation and my Atari ST (no flames please) really fine. The current version of Mtools and all the patches are available via anonymous ftp from cerl.cecer.army.mil (129.229.1.101). -- Dipl.-Inform. Rainer Klute klute@irb.informatik.uni-dortmund.de Univ. Dortmund, IRB klute@unido.uucp, klute@unido.bitnet Postfach 500500 |)|/ Tel.: +49 231 755-4663 D-4600 Dortmund 50 |\|\ Fax : +49 231 755-2386