This is Optical-Disk in view mode; [Up]
Date: Sun 01-Nov-1989 10:52:21 From: Unknown Subject: Optical Disk Ok, so I went and sat next to the cube, at the console of the machine. I finally opened the cover of "the bad optical disk", an 0.8 distribution disk that we designated to become a "tar" backup disk. This is the one that's been causing me trouble for a while. It looked like someone had sneezed on the media, both sides were covered with dirt. Now, (the owner) Karp's office, where the machine resides, gets a substantial amount of street dirt, and diesel bus exhaust in the window, that deposits itsself over everything in his room. What's a bit upsetting, is that it apparently got all over "the bad optical disk" just by it's being out of it's sleeve in the drive in the cube, the place where that disk spent most of its life. Implying that there's no air filtration in the machine for the optical disk mechanism. The history of the disk was that it had overflowed its bad block table. Re-initializing the disk with the disk "bulk" (UNDER 1.0!) command emptied the badblock table. The "all" command annoyed Karp by putting a graph on the main screen, even though I had run it from an rlogin port. Even though I ran the "all" command (check all blocks), outputting no graph and text to /dev/null, it ran for over a day without completing. Maybe that's reasonable for that large of a disk, but I suspect the printf of the time and date followed by a carriage return slows it down quite a bit. (You can't turn that off.) This may be a warning to folks with machines in dirty environments (perhaps near printers and copiers, and things that dump sticky particulates), you may want to worry about what kind of air goes through the cube. There IS now a man page on the "disk" command, thank you, NeXT, but still none that I can see on the OD. There are some interesting things I'd like to know about the OD, like "does it really verify all writes" and what the permissible level of retries is, and how it handles things AFTER a badblock table fills up. And how to force ejects, and how to actually USE the the stuff in /usr/include/nextdev/{disk.h,canon.h, odvar.h,odreg.h}. I second the motion to the fellow who wants to be able to mount and unmount and use the optical disks without the person at the console having to know about it or deal with it. And to be able to have disks for raw data that are NOT automount, and don't immediately eject. In particular, if someone is going to make the device practical for a stack loader, or juke box, it needs the disk handling to work without intervention. Joe Stong jst@cca.ucsf.edu >From: epsilon@wet.UUCP (Eric P. Scott)
These are the contents of the former NiCE NeXT User Group NeXTSTEP/OpenStep software archive, currently hosted by Marcel Waldvogel and Netfuture.ch.