lphillips@lpami.wimsey.bc.ca (Larry Phillips) (01/13/90)
In <7644@hubcap.clemson.edu>, robert@hubcap.clemson.edu (Robert Reynolds) writes: > >1. Having copied a fairly large file (~150K) from hard disk to RAM: >successive cmp's (byte-for-byte comparison) of the two files are >inconsistent -- like of five successive cmp's two or three claim a >difference between the files. > >2. But ... when cmp claims a difference it's always at the same place in >the file ... sort of. "Sort of" because if I re-copy the file the >location of the difference sometimes changes. > >3. Now the really nifty part. There's an option to cmp to list the >differences. The RAM: file is always correct. The data cmp thinks is >coming from disk is 44 4f 53 xx repeated over and over again with the xx >changing in fairly regular fashion, except for the rare occasion when >it's missing. The ASCII translation of that sequence is DOSxDOSxDOSx. The 44 4f 53 xx, with the xx changing regularly is probably 'format' data, that is, data that is laid down by the Amigados FORMAT command. It is exactly what you will see if you take a look at a formatted disk with a sector editor. Suggestions and questions: Are you running any disk buffering programs? (BlitzDisk, modified FACC, etc.) Is the 'cmp' trustworthy? Can you copy a file to a floppy and have it compare OK? Can you copy the file from RAM: to RAM: (under a different name, of course), and compare them? If you copy the file to RAM: under two different names, then compare each in turn with the original disk file, do they miscompare in the same spot in the file? Do the two files in RAM: compare OK? Could there possibly be any overlapping partitions on your drive? Does your controller require a MaxTransfer entry in the mountlist? Even if it isn't stated, try setting MaxTransfer to some different values. Start with, say 128K ( MaxTransfer = 131072 ), and reduce it in stages down to 512 bytes. >I'll be delighted to provide more detailed information. I'm really >getting sick of mis-reads! The disk system is a Pacific Peripherals >Overdrive and ST157N. The Amiga is a 2000 with a rev 4.something >motherboard. I have 3M memory, and I really don't recall what kind of >expansion board it is. Like I said, I'll be delighted to provide more >detailed information if it'll help someone nail down my problem. Information that might be of help: Mountlist entry for all partitions on the drive. Software running 'in background' (mouse accelerators, GOMF, Snipit, etc.) -larry -- "Cavett Emptor - Let the talk show host beware!" - Evan Marcus +-----------------------------------------------------------------------+ | // Larry Phillips | | \X/ lphillips@lpami.wimsey.bc.ca -or- uunet!van-bc!lpami!lphillips | | COMPUSERVE: 76703,4322 -or- 76703.4322@compuserve.com | +-----------------------------------------------------------------------+
robert@hubcap.clemson.edu (Robert Reynolds) (01/14/90)
I finally have some clues to a hard disk problem I've been having for a while, and I'm hoping they'll mean something to someone out there. Please help! Herewith the clues: 1. Having copied a fairly large file (~150K) from hard disk to RAM: successive cmp's (byte-for-byte comparison) of the two files are inconsistent -- like of five successive cmp's two or three claim a difference between the files. 2. But ... when cmp claims a difference it's always at the same place in the file ... sort of. "Sort of" because if I re-copy the file the location of the difference sometimes changes. 3. Now the really nifty part. There's an option to cmp to list the differences. The RAM: file is always correct. The data cmp thinks is coming from disk is 44 4f 53 xx repeated over and over again with the xx changing in fairly regular fashion, except for the rare occasion when it's missing. The ASCII translation of that sequence is DOSxDOSxDOSx. I'll be delighted to provide more detailed information. I'm really getting sick of mis-reads! The disk system is a Pacific Peripherals Overdrive and ST157N. The Amiga is a 2000 with a rev 4.something motherboard. I have 3M memory, and I really don't recall what kind of expansion board it is. Like I said, I'll be delighted to provide more detailed information if it'll help someone nail down my problem. Robert Reynolds inet: robert@hubcap.clemson.edu CS Dept, Clemson Univ. uucp: ... !gatech!hubcap!robert phone: (803) 656-6783 -- Robert Reynolds inet: robert@hubcap.clemson.edu CS Dept, Clemson Univ. uucp: ... !gatech!hubcap!robert phone: (803) 656-6783