rcb@binstock.osf.org (R.C. Binstock) (01/09/91)
Since I got my hard disk and (old) Apple SCSI card, I have been using the backupII program from the /scsi.utilities disk that came with the SCSI card to back up the disk to 5.25" floppies. I recently acquired a Laser 3.5" drive and UDC. They work fine with all my software except backupII. As far as I can tell, although backupII seems to correctly read the size (1600 blocks) of the disk at first (it appears to correctly calculate the number of disks needed for backup), it does not stop writing when the first backup volume reaches the appropriate size. It fails with a "Write error: replace bad disk" message and when I catalog the disk, all 1600 blocks are full. Backup (35 or 40 5.25" disks) was my main reason for getting the 3.5" drive, so this is kind of a drag. I'd appreciate any suggestions about: what's wrong; what I can do to get backupII to work; other software I might easily and cheaply obtain (I can't download) that would do the job for me; or any solution to my problem. Thank you very much. Bob Binstock
CMDSEN@primeg.weeg.uiowa.edu (01/09/91)
R.C. Binstock (Bob Binstock) recently commented on problems backing-up his harddrive using a UCD/Laser 3.5 drives with backupII. I think the problem lies with the UDC or Laser drives, not backupII, per se. I also have a couple IIe's with HD (10Meg Sider, 40Meg Vulcan) and UDC/Laser 3.5 combo's. When using BackupII I usually get a bad block when BackupII tries to verify the disk after writing - hence no valid backup is done. Yes, Bob, all 1600 blocks should be full. BackupII splits files across disks to use all blocks. No ProDOS volume directory is there in the traditional sense. Your 'bad disk' probably has a bad block on it. The UDC or Laser3.5 just isn't reliable enough. I don't know is the backup utility in ProSel will work better. Most pgms will be OK with the UDC. BackupII won't. I think Apple's FastCopy won't work either. Printing a file to disk from AppleWorks 3.0 often causes bad blocks with a UDC. I suspect the problem is related to the buffer size being written at a time. Programs using smaller buffer sizes work better. I use Davex for file management and have few problems because the file buffers are small (or so I think). It is also due to Dave's great coding :-) In summary I think your problem is really the UDC or Laser drives, not the backup program. Sorry :-( If you find a solution, pass it on. I've been bad-mouthing the UDC for a couple years now! -Steve Nelson Internet: cmdsen@primeg.weeg.uiowa.edu Bitnet: cmdsenpg@uiamvs
rcb@binstock.osf.org (R.C. Binstock) (01/09/91)
Steve Nelson suggested that my problems with BackupII have to do with the UDC. That may well be, but I'm pretty sure it's not from a bad block, but rather from BackupII not stopping before the disk is full. When I check the disks afterwards they never have bad blocks. Also, I've experimented by removing the file that was transferring when the write error occured, and the error then occurs on the next file, every time. In other words, BackupII always transfer the same amount of data -- 1600 blocks -- then fails.
jeffb@world.std.com (Jeffrey T Berntsen) (01/10/91)
rcb@binstock.osf.org (R.C. Binstock) writes: >Steve Nelson suggested that my problems with BackupII have to do with >the UDC. That may well be, but I'm pretty sure it's not from a bad >block, but rather from BackupII not stopping before the disk is full. >When I check the disks afterwards they never have bad blocks. Also, >I've experimented by removing the file that was transferring when the >write error occured, and the error then occurs on the next file, every >time. In other words, BackupII always transfer the same amount of >data -- 1600 blocks -- then fails. What version of Backup II do you have? I seem to recall someone from Apple on CI$ or GEnie saying that the oldest versions of Backup II have that problem and newer ones don't. I don't know exactly which versions do or don't have the problem but I think it would be safe to assume that version 1.0 does and whatever version comes with the DMA SCSI card might not. ----------------------------------------------------------------------------- Jeffrey T. Berntsen | Looking for a good .sig jeffb@world.std.com | -----------------------------------------------------------------------------