Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.2 9/5/84; site reed.UUCP Path: utzoo!linus!philabs!prls!amdimage!amdcad!amd!pesnta!hplabs!tektronix!reed!bart From: bart@reed.UUCP (Bart Massey) Newsgroups: net.micro.mac Subject: Re: Re: Junkware Message-ID: <1813@reed.UUCP> Date: Sun, 18-Aug-85 17:51:20 EDT Article-I.D.: reed.1813 Posted: Sun Aug 18 17:51:20 1985 Date-Received: Fri, 23-Aug-85 08:16:23 EDT References: <2957@seismo.UUCP> <481@oakhill.UUCP> Organization: Reed College, Portland, Oregon Lines: 30 In article <481@oakhill.UUCP> davet Dave Trissel writes: > > In article <2957@seismo.UUCP> mo (Mike O'Dell) writes: > > > >Correct me if I'm wrong, but if the little button on the disk is OPEN > >the disk is write-protected, no?? ... > > Well - sort of. The problem is that it's only *SOFTWARE* write protected. > It seems the Mac drives themselves do not inhibit writes no matter what > the position of the tabs. The Mac O/S gets a signal about the tab position > and sets up flags which are supposed to not allow any writes. > > So don't think the tab will protect you from program/machine malfunction. > (I learned this the NASTY way.) > > Here's hoping future Mac drives are smart enough to just plain refuse to > write data if the tab says so regardless of what the OS tells it. Of course, > banning the bomb (i.e. memory protection so programs cannot clobber the OS) > is a far bette solution. Actually, both should be implemented. I guess! I CAN'T BELIEVE THIS! Didn't the @#$% idiots who designed this mess take hardware 101? I guess the new DS drives may fix the problem, and I guess machines with an MMU wouldn't necessarily have it (although one would have to be awfully careful about what bit-copier software you let have control of the system address space (how would a bit-copier work on a memory-managed machine, anyway?)) but it sounds like we're just stuck for now. Thanks, Dave, for warning us of this... Bart Massey ..tektronix!reed!bart