Path: utzoo!utgpu!watserv1!watmath!att!occrsh!uokmax!apple!usc!wuarchive!zaphod.mps.ohio-state.edu!swrinde!ucsd!pacbell.com!decwrl!csus.edu!ucdavis!csusac!csuchico.edu!csuchico.edu!mrush From: mrush@csuchico.edu (Matt "C P." Rush) Newsgroups: comp.sys.amiga.hardware Subject: fsck WAS: Obsessive Multitasking and Amiga File I/O Scheduling Message-ID: <1990Sep11.231523.3863@ecst.csuchico.edu> Date: 11 Sep 90 23:15:23 GMT Sender: news@ecst.csuchico.edu (USENET) Reply-To: mrush@csuchico.edu Followup-To: Organization: California State University, Chico Lines: 61 In-reply-to: CHUCK.PHILLIPS.90Sep9155105@halley.FtCollins.NCR.COM > DISCLAIMER: Included are some file system experiments. They are supplied > for entertainment value only. Neither I nor my employer can take > responsibility for the results. Performing either **PROBABLY WILL** trash > your disk. YOU'VE BEEN WARNED! {Lot's of stuff deleted} > Well, _I_ don't have to try very hard. Try turning off your machine > _while_ an application is in the middle of writing a large file, and tell > me what you find when you reboot. That sort of thing is going to trash a lot of small systems. Unless you've got some kind of power filtering/UPS a powerfailure is going to create some pretty nasty magnetic pulses around that disk drive... > Alternately, write a small program that > opens a file for writing then exits without closing the file. Now try to > access the file. Any problems? On a more practical-experience note: I have. Frequently. The non-shared Write Lock makes that file unaccessable to other/new tasks UNTIL such time as the system is rebooted (and I assume the Disk- Validator does its trick). But the data is usually STILL THERE and the disk is certainly NOT corrupted (as was implied might happen). > Of course, neither of these would _ever_ happen during normal use, unless > there is a power failure, a program crashes or your machine GURUs. ;^) > Other contributing causes: Running a program before it's debugged, using PD > software, allowing a novice anywhere near your machine, interrupting a > running program, rebooting or turning off your machine (just because you > _think_ no processes have open files), etc. "Normal" use? What is "NORMAL" use? :-) I haven't had the power failure, or the novice user problems, but all the other have occured. Yes, I agree that AmigaDOS is not the most reliable File System around, but they all have some drawbacks (just for fun, try deleteing the . or .. dir on a MS-DOG disk :-). My point was strictly to say that beyond the handling of the FLOPPY disks, CBM can NOT be held _completely_ responsible, and that since the Amiga is a SINGLE-USER multitasking system it is up to that single user to take at least a little part in the scheduling of tasks (as it were, wait until AFTER you copy your 300k to your floppy before you issue DIR OPT A :-) Bonus Disclaimer: This is NOT intended to be a flame. Also, our news-reader has been buggering up, so I had to do this follow-up using Pnews. My appologies to any involved/quoted parties that were not correctly identified. -- Matt *~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~* % "Progress is an up-hill battle % mrush@csuchico.edu % % against backwards compatibility." % mrush@cscihp.UUCP % % -- me % % Now: mrush@cscihp.ecst.csuchico.edu % *~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~* This is a SCHOOL! Do you think they even CARE about MY opinions?!