jms@tardis.Tymnet.COM (Joe Smith) (08/25/89)
Let me say that I find Kent's arguments valid but not convincing. In article <13304@well.UUCP> xanthian@well.UUCP (Kent Paul Dolan) writes: >Never the less, Andy and other CATS types, this is a bug, not a feature, >since it is guaranteed to cause grief to old software, and to new users, >and most of all (I'm shouting here, listen up ;-) IT WASN'T NECESSARY! Oh, but it was. The bugs in the old RAM disk driver did not affect CLI users or execute scripts, but it did affect properly written software that looked at the device. A change *was necessary*. [a bunch of unconvincing statements deleted] >Don't tell me it isn't your fault. Don't tell me some arcane way to get >around it. Don't tell me it is no big deal. Fix it. Do you want all the old bugs back? That's what it sound like you're demanding. CATS would probably be more receptive to "Please change the default label of the RAM disk" than to "You're a bunch of fools, fix it!" >(And by the way, if relabel works for RAM:, it should always work, as >should diskchange.) In my other posting, I recommended doing "makedir RAM:t" for a reason. The reason is that "makedir" and "dir" (and just about any other access to RAM:) will create the RAM disk. This separates the operation into two steps: first create the RAM disk, then relabel it. If "relabel" does not work when RAM: does not yet exist, then that is something worth complaining about. -- Joe Smith (408)922-6220 | SMTP: JMS@F74.TYMNET.COM or jms@tymix.tymnet.com McDonnell Douglas FSCO | UUCP: ...!{ames,pyramid}!oliveb!tymix!tardis!jms PO Box 49019, MS-D21 | PDP-10 support: My car's license plate is "POPJ P," San Jose, CA 95161-9019 | narrator.device: "I didn't say that, my Amiga did!"