greg@bilbo (Greg Wageman) (03/24/89)
A while ago there was a posting stating that it is possible to write
on a disk with the write-protect hole open (write-protected). Most of
us were skeptical, wanting to see schematics to know if this was, in
fact, possible.
I have not seen any schematics, but I have witnessed, first-hand, a
write-protected disk being altered by a program.
The program is the Atari CP/M-Z80 emulator, which I downloaded from
GEnie. I had write-protected the "system" disk to prevent mistakenly
deleting files during a previous operation, and had forgotten to
write-enable it again. I gave the CP/M "era" command to delete a file
from the disk. The disk made some *very* unusual sounds, and I got an
error from the emulator indicating that the disk was bad ("BDOS error
on A: bad sector"). I tried again; same result. When I did a "dir",
the file was gone. I removed the disk from the drive, to look at it,
and was shocked to discover that even though it was still
write-protected, the emulator had succeeded in deleting the file!
Now, I don't claim to know at what level the CP/M emulator is driving
the hardware. Since the CP/M emulator writes its own disk format,
it's probably doing physical I/O via "rwabs" at least. It's possible
that you can't get this behaviour through the normal TOS calls; I
simply don't know for sure.
I can tell you this, though: I'm going to be a lot more careful about
what I do, even if the disk *is* write-protected. No smiley.
Longish .signature follows. Skip now, or don't complain!
Greg Wageman DOMAIN: greg@sj.ate.slb.com
Schlumberger Technologies UUCP: ...!uunet!sjsca4!greg
1601 Technology Drive BIX: gwage
San Jose, CA 95110-1397 CIS: 74016,352
(408) 437-5198 GEnie: G.WAGEMAN
------------------
There is only one "r" in "pejorative"
------------------
Opinions expressed herein are solely the responsibility of the author.
(And the author wouldn't have it any other way.)sl161011@silver.bacs.indiana.edu (Kevin Clendenien) (03/25/89)
In article <769@snjsn1.SJ.ATE.SLB.COM> greg@sj.ate.slb.com (Greg Wageman) writes: >the file was gone. I removed the disk from the drive, to look at it, >and was shocked to discover that even though it was still >write-protected, the emulator had succeeded in deleting the file! Greg, I have not used the CP/M emulator, so I can only conjecture on this subject, but it is important to understand a couple of things about the emulator. It is possible that the emulator did not actually delete the file, but merely removed it from the directory of the disk that it keeps in memory. Thus, when you did a DIR command, the file was reported as gone because it no longer showed up in the directory that the OS contained in memory. Did you at any point after "deleting" this file, reboot the emulator and then execute a DIR command? The rebooting of the emulator would have cleared the directory in memory, and forced the emulator to reread the directory from disk, possibly recovering the "lost" file. I have been lead to believe that the Atari drives use much the same mechanism as the IBM 3.5" drives. If this is the case, and there is no reason for Atari to have changed the mechanisms themselves (not even to save money) then there is NO WAY THROUGH SOFTWARE to write to a write protected disk. Even if the operating system ignores some signals from the disk drive, the write protect signal is used internally by the drive, to allow it to decide whether or not is should executed a write request from the computer. The fact that the CP/M emulator returned an error message leads me to believe that it did not really write to the disk. ----------------------------------------------------------------------------- sl161011@silver.UUCP Kevin B. Clendenien -----------------------------------------------------------------------------
hase@netmbx.UUCP (Hartmut Semken) (03/31/89)
In article <769@snjsn1.SJ.ATE.SLB.COM> greg@sj.ate.slb.com (Greg Wageman) writes: >A while ago there was a posting stating that it is possible to write >on a disk with the write-protect hole open (write-protected). Most of >us were skeptical, wanting to see schematics to know if this was, in >fact, possible. Whether this is possible or nor depends on the drive used. My Teac FD55F and Mitsumi 3.5 inch floppy do not write to write-protected disks. If I disconnect the -WR line from the drives to the ST and pull it up (10kOhms to +5Volts) on the ST side, the ST 'writes' to the disk, but rereading it displays an unchanged directory. Nothing really gets written. The read/write amplifier in the Teac is disabled by the internal WriteProtect signal. So it is not possible to write to write protected disks. Some NEC 1036 and 1037 do write to writeprotected disks (confirmed); my Aplle Disk ][ (with an Apple ][) does the same... hase -- Hartmut Semken, Lupsteiner Weg 67, 1000 Berlin 37 hase@netmbx.UUCP If there is something more important than my Ego, I want it caught and shot. Now! (Zaphod Beeblebrox)
greg@bilbo (Greg Wageman) (04/01/89)
In article <2481@netmbx.UUCP> hase@netmbx.UUCP (Hartmut Semken) writes: >In article <769@snjsn1.SJ.ATE.SLB.COM> greg@sj.ate.slb.com (Greg Wageman) writes: >>A while ago there was a posting stating that it is possible to write >>on a disk with the write-protect hole open (write-protected). Most of >>us were skeptical, wanting to see schematics to know if this was, in >>fact, possible. > >Whether this is possible or nor depends on the drive used. > >My Teac FD55F and Mitsumi 3.5 inch floppy do not write to >write-protected disks. > >If I disconnect the -WR line from the drives to the ST and pull it up >(10kOhms to +5Volts) on the ST side, the ST 'writes' to the disk, but >rereading it displays an unchanged directory. Nothing really gets >written. > >The read/write amplifier in the Teac is disabled by the internal >WriteProtect signal. So it is not possible to write to write protected >disks. > >Some NEC 1036 and 1037 do write to writeprotected disks (confirmed); >my Aplle Disk ][ (with an Apple ][) does the same... Yup, this is correct. What fooled me was that the OS altered the *cache*, and when the write to the disk failed, it didn't re-read the disk and update the cache. A subsequent 'dir' command displayed the (erroneous) cache data. The file would have reappeared after a forced media change. Sorry about that. Longish .signature follows. Skip now, or don't complain! Greg Wageman DOMAIN: greg@sj.ate.slb.com Schlumberger Technologies UUCP: ...!uunet!sjsca4!greg 1601 Technology Drive BIX: gwage San Jose, CA 95110-1397 CIS: 74016,352 (408) 437-5198 GEnie: G.WAGEMAN ------------------ There is only one "r" in "pejorative" ------------------ Opinions expressed herein are solely the responsibility of the author. (And the author wouldn't have it any other way.)