luc@kulcs.UUCP (Luc Van Braekel) (09/25/86)
1) Recently i read the following (translated) in the Dutch magazine "Commodore Dossier": > Remember that even renowned programs like Vizawrite use the disk- > corrupting 'SAVE "@0:...."'-command. Using a new name and > scratching is safer. Why is that command disk-corrupting ? Is it unsafe just because if something goes wrong during saving, your file is corrupted, or is there more to it (like a bug in the drive o.s.) ? 2) I frequently have read-errors when trying to save files when my diskdrive has been on for, say, more than 2 hours. After switching it off and letting it cool for a few minutes, everything is OK again. Any solutions ? 3) I heard that the annoying clicking sound of the 1541 drive has something to do with the head positioning on track 1. Does this mean that if you don't use track 1, the drive won't click ? I noticed that there's a lot of clicking before bad reads. Luc Van Braekel, Department of Computer Science, Katholieke Universiteit, Leuven, Belgium (...seismo!prlb2!kulcs!luc)
rra202@uiucuxa.CSO.UIUC.EDU (09/27/86)
The problem with the SAVE"@0:filename" command on a 1541 (and I think EARLY 1571) is that it scratchs the file FIRST and then writes the new one. If the new one has grown so large it overflows the disk, or if some other problem occures after the scratch but before the file is written completely, you lose. Later 1571's write the new file first, scrtch the old one , and then rename the new one to the old ones name. It means you need lots of empty space on the disk , but this problem doesn't occure The rattling comes from the read arm hitting it's stop. Many programs send the arm out as far as it will go, as a means of getting to a known possision Try formatting a blank disk, and the rattle you hear at the begining is this.
6080733@PUCC.BITNET (Gavin Bell) (09/28/86)
In article <140@kulcs.UUCP>, luc@kulcs.UUCP (Luc Van Braekel) writes: 1) Is there a bug in the drive OS [regarding SAVE@]... Yep, there sure is a bug, and it apparently shows up in almost every drive Commodore has ever made. It is pretty obscure, but nasty-- it can even hit you if you scratch the file and then immediataly resave (it has happened to me). What happens is you get a weird file in the directory, consisting of bits of other files (I think...) which is impossible to get rid of without a lot of knowledge about DOS and a disk doctor program. I hear you can avoid the problem by ALWAYS specifying the drive number in your commands (i.e. "s0:file" save "0:file"), but I make it a practice to re-initialize the drive after scratching any file ( "s0:file" ... "i0" ... save "0:file"). >2) I frequently have read-errors when trying to save files when my > diskdrive has been on for, say, more than 2 hours. After switching > it off and letting it cool for a few minutes, everything is OK > again. Any solutions ? I used to have problems with drive over-heating, too. Try either taking off the top cover and metal shielding of the drive (keeps mine nicely cool even during hot California summers) or buying an inexpensive muffin-fan and sitting it on top of the drive (they can be bought for < $15 at some electronics dealers). >3) I heard that the annoying clicking sound of the 1541 drive has > something to do with the head positioning on track 1. Does this > mean that if you don't use track 1, the drive won't click ? > I noticed that there's a lot of clicking before bad reads. The clicking on track 1 is the drive head hitting the end-position stop-- the clicking before a bad read is the drive head moving around trying to find the right track. A good "disk doctor" program will let you adjust the end-stop to stop any clicking, and will also let you re-align the head so your read errors should go away (all this with just a phillips screwdriver, too.) Frederick J. Bear (I have too much hair-- SCARE Fred Bear!) UUCP: ...allegra!psuvax1!pucc.bitnet!6080733 BITNET: 6080733@PUCC
drg@briar.UUCP (Don Gentner) (10/01/86)
In article <140@kulcs.UUCP>, luc@kulcs.UUCP (Luc Van Braekel) writes: > Why is that command [@save] disk-corrupting ? Is it unsafe just because if > something goes wrong during saving, your file is corrupted, or is > there more to it (like a bug in the drive o.s.) ? There is a more serious problem then just trying to do a save with replace when your disk is full. There is a real bug in the DOS that corrupts the disk on occasional save with replace commands. I've been bitten three times (I'm a slow learner) and have finally completely forsaken the command. In my experience, the problem occurs when you are using SAVE@ with two files. Under some circumstances, when you do a SAVE@ of file A, the directory entry is updated properly, but the BAM is not updated. You are now in trouble, but it is not obvious because file A will load and list properly. Presumably validating the disk at this point would cure the problem. If instead you load file B, edit it, and then do a SAVE@ of file B, it will overwrite file A because the space for A was not allocated in the BAM. The end result is that the directory entries for both A and B point to file B, and file A is lost. For more details and a demonstration of the bug see "SAVE with Replace Exposed!!" in the July 1985 issue of The Transactor, and "Save with Replace: Debugged at Last" in the October 1985 issue of Compute!. The basic advice in Compute! is, "Therefore, the key to avoiding the SAVE@ bug is to always specify drive 0 when performing any disk drive function, or to always reset the drive before any SAVE@ operation." Because I've forsworn this evil command, I can't verify that this advice works. Don Gentner philabs!gentner@seismo.arpa