elg@killer.UUCP (Eric Green) (08/23/87)
in article <252@uwslh.UUCP>, lishka@uwslh.UUCP (Christopher Lishka) says: > In article <2214@cbmvax.UUCP> eric@cbmvax.UUCP (Eric Cotton) writes: >>A word of caution here: It is not advisable to use save-with-replace on >>the old 1541 disk drives. Delete the file first and then save the new >>version. >> >> Eric Cotton >> Commodore-Amiga > > Hmmmm... I *have* been using the @0: command on my old 1541 drive > since I have had it (four or five years now), and have NEVER had any > problems. Luck, Christopher. I lost a LOT of work with save-with-replace. This happened in an assembly-language-develpment environment, with me saving the text back to disk about once every 5 minutes, using the @0: (WITH the zero -- I'd heard about that, too). It didn't help. I eventually ended up with a "Not Source File" error, and when I went and looked at the disk with Disk Doctor, it was obvious why -- my source file had disappeared into la-la land, after the first couple of sectors, it then sorta mosied on over and became part of a binary file. This has happened to me several times under several different environments (1541, semi-modern ROM, both Merlin and PAL assemblers). It also happened to me with Easy Script, which especially loved eating files if you didn't scratch them first. I've never had problems on my SFD-1001 (although you must use the zero there, too -- apparently, when Commodore designed the SFD, they forgot that it was no longer a dual drive, so you can access drive 1, and the SFD locks with a "drive not ready?" error!). -- Eric Green elg%usl.CSNET Ollie North for President: {cbosgd,ihnp4}!killer!elg A man we can believe (in). Snail Mail P.O. Box 92191 Lafayette, LA 70509 BBS phone #: 318-984-3854 300/1200 baud
desmarai@iros1.UUCP (Stephane Desmarais) (09/11/87)
In article <1387@killer.UUCP> elg@killer.UUCP (Eric Green) writes: >in article <252@uwslh.UUCP>, lishka@uwslh.UUCP (Christopher Lishka) says: >> I *have* been using the @0: command on my old 1541 drive >> since I have had it (four or five years now), and have NEVER had any >> problems. > >Luck, Christopher. I lost a LOT of work with save-with-replace. This happened >... using the @0: (WITH the zero -- I'd heard about that, too). It didn't help. Well, that matter was settled a while back in Compute or Compute Gazette Magazine (I don't remember which one, or when). The bug DOES exists and has to do with the fact of NOT specifying the unit number (0 or 1) EVERYWHERE, confusing the DOS in the drive about the free sectors map (bam). Basically, you are supposed to use the 0: when you load, save, open a file for I/O, or load the directory (load "0:$",8) (everywhere). Only THEN will you be sure of not having any trouble. Or you can power down and then on the drive just before using @0:. Or isue the disk command "uj" which does a reset of the drive. Or better, don't take any chances: erase and then save; your work his precious (well, I hope so :-). P.S. I did loose files before knowing that :-(and even after, when my brother had the "bright" idea of using it on one of my important disks, and did'nt know about the bug...). -- cccc 666 4 Stephane Desmarais c c 6 44 Departement d'informatique c == 6666 4 4 Universite de Montreal c c 6 6 44444 seismo!utai!musocs!mcgill-vision!iros1!desmarai cccc 666 4 <desmarais%iro.udem.cdn@ubc.csnet>
lishka@uwslh.UUCP (Christopher Lishka) (09/19/87)
In article <270@Mannix.iros1.UUCP> desmarai@iros1.UUCP (Stephane Desmarais) writes: >In article <1387@killer.UUCP> elg@killer.UUCP (Eric Green) writes: >>in article <252@uwslh.UUCP>, lishka@uwslh.UUCP (Christopher Lishka) says: >>> [My message concerning never losing files with @0:] >> >> [A kind person replying to warning me of the danger...] > > [Another person warning me that I have been confused] Since I am the one who started this (again, 'cause I am sure it's been discussed before), I will hopefully formally close this discussion. I have been a fool. I thought I was safe because I specified the drive number in the command itself, but I did not realize I had to specify the drive every time. Oh well, guess I can't use that command anymore... [quiet sobbing] it is a real nuisance to have to delete the old file and then resave, and dangerous as well. But if the @0: command does not work properly, as Curtis Blow sang "These are the breaks!" >Or issue the disk command "uj" which does a reset of the drive. One place where I used the command a lot was in my Cpower work disk, but since I used fastload, I always had to send a 'disk u;' command after a major operation. That probably saved my butt quiter often. *** A final question *** Does the fastload cartridge fix the @0: command problem? How about Elite's fast load software? Those are the two programs I use the most, and I would like to keep using it in these two places. Anyone have the answers? One funny ending comment...I have never had problems with the command. In the end, I have never had lost files, although I may have had a small problem with blocks not being freed up in the bitmap when I delete something, but that happened only with one disk. I must stress that I used the @0: command a h*ll of a lot, and had nearly no trouble, no corrupted files of file systems, no pains. I must've been damned lucky. Live and learn.............. -Chris -- Chris Lishka /lishka@uwslh.uucp Wisconsin State Lab of Hygiene <-lishka%uwslh.uucp@rsch.wisc.edu \{seismo, harvard,topaz,...}!uwvax!uwslh!lishka