Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!elroy.jpl.nasa.gov!mahendo!nereid!john From: john@nereid.jpl.nasa.gov (John Veregge) Newsgroups: comp.sys.amiga.datacomm Subject: Re: ftp->mtools->d2d->Zoo->corrupt files Keywords: ftp mtools d2d zoo sun sparc Message-ID: <6062@mahendo.Jpl.Nasa.Gov> Date: 25 Jan 91 15:30:04 GMT References: <6057@mahendo.Jpl.Nasa.Gov> <6060@mahendo.Jpl.Nasa.Gov> Sender: news@mahendo.Jpl.Nasa.Gov Reply-To: john@nereid.jpl.nasa.gov (John Veregge) Organization: Technology Development Group (JPL) Lines: 62 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