esker@abaa.uucp (Lawrence Esker) (09/07/89)
In article <20932@sequent.UUCP> dmose@crg3.UUCP (Dan Mosedale) writes: >>VD0: requires the file vdisk.device to be loaded in the DEVS: directory. >>Mountlist should specify Device=vdisk.device >> >> Michael > >Just tried this, and it still doesn't work... > >sequent!dmose I doubt if this is your problem, but for everyone else: BUG WARNING The Mount program is case dependent on the "Device=" line. I had many fits on the RAD: device when I used "Device = RamDrive.device". Mount would not mount the device AND never gave any error messages. Only thing that worked was "Device = ramdrive.device". -- ---------- Lawrence W. Esker ---------- John Baier's VAX process name: 0<2do~:-):-):-) UseNet Path: __!mailrus!sharkey!itivax!abaa!esker == esker@abaa.UUCP
perry@madnix.UUCP (Perry Kivolowitz) (09/09/89)
In article <2493@abaa.UUCP> esker@abaa.UUCP (Lawrence Esker) writes: >The Mount program is case dependent on the "Device=" line. I had many fits >on the RAD: device when I used "Device = RamDrive.device". Mount would not >mount the device AND never gave any error messages. Only thing that worked >was "Device = ramdrive.device". You are absolutely right, but for the wrong reasons. It isn't actually mount's fault. It turns out the the operating system must find a match between a device or libraries external and internal names. Un- fortunately, the match is case sensitive. Almost nowhere else in the system does case matter. But here. It matters. This should be considered a bug and fixed. -- Perry Kivolowitz, ASDG Inc. ARPA: madnix!perry@cs.wisc.edu {uunet|ncoast}!marque! UUCP: {harvard|rutgers|ucbvax}!uwvax!astroatc!nicmad!madnix!perry CIS: 76004,1765 (what was that about ``giggling teenagers''?)
papa@pollux.usc.edu (Marco Papa) (09/10/89)
In article <838@madnix.UUCP> perry@madnix.UUCP (Perry Kivolowitz) writes: >In article <2493@abaa.UUCP> esker@abaa.UUCP (Lawrence Esker) writes: >>The Mount program is case dependent on the "Device=" line. I had many fits >>on the RAD: device when I used "Device = RamDrive.device". Mount would not >>mount the device AND never gave any error messages. Only thing that worked >>was "Device = ramdrive.device". > >You are absolutely right, but for the wrong reasons. >It isn't actually mount's fault. It turns out the the operating system must >find a match between a device or libraries external and internal names. Un- >fortunately, the match is case sensitive. >Almost nowhere else in the system does case matter. But here. It matters. Quite true, Perry. In fact, if one tried to do something like: Atalk3 DEVICE Serial.Device the device won't open, BUT a subsequent (correct) call: Atalk3 DEVICE serial.device will also fail, for the reasons Perry mentioned. At that point only a reboot will free the device. >This should be considered a bug and fixed. Yep. (I am sending this to cbm, just in case you haven't done so). -- Marco Papa 'Doc' -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= uucp:...!pollux!papa BIX:papa ARPAnet:pollux!papa@oberon.usc.edu "There's Alpha, Beta, Gamma, Diga and Caligari!" -- Rick Unland -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
mlelstv@immd4.informatik.uni-erlangen.de (Michael van Elst ) (09/14/89)
papa@pollux.usc.edu (Marco Papa) writes: >Quite true, Perry. In fact, if one tried to do something like: >Atalk3 DEVICE Serial.Device >the device won't open, BUT a subsequent (correct) call: >Atalk3 DEVICE serial.device >will also fail, for the reasons Perry mentioned. At that point only a reboot >will free the device. I got this bug when I wrote a hard disk driver and named the created file different from what was mentioned in the Resident structure. (That's not quite the same but a similar problem). The bug is: ramlib.library of DOS or whoever checks if the name passed to OpenDevice is entered into the device list. Now the device doesn't see this name and installs itself with another name. The devicelist is checked and the device requested is not found. NOW: the device is UnLoadSeg'd from memory !!!! the device will surely be destroyed during the next memory allocation. I got the guru when first expunging the device resulting in #81000009 (memory freed already free). Michael van Elst E-mail: UUCP: ...uunet!unido!fauern!immd4!mlelstv