Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!magnus.acs.ohio-state.edu!usenet.ins.cwru.edu!gatech!mcnc!taco!hobbes.catt.ncsu.edu!kdarling From: kdarling@hobbes.catt.ncsu.edu (Kevin Darling) Newsgroups: comp.os.os9 Subject: Re: open() + sharable file = no disk Message-ID: <1991Jun12.051830.4900@ncsu.edu> Date: 12 Jun 91 05:18:30 GMT References: <1991Jun11.012640.904@tkou02.enet.dec.com> <1656@seq.uncwil.edu> <1991Jun12.012958.10534@tkou02.enet.dec.com> Sender: news@ncsu.edu (USENET News System) Organization: North Carolina State University Lines: 28 zambotti@wpowz.enet.dec.com (Walter Zambotti DEC) writes: > I having a small problem with the open() system call. > Now I have been testing this code on the Tandy Development pack RAMDISK > (/r0) and this could possibly be just the ramdisk driver screwing up. and session@seq.uncwil.edu (Zack C. Sessions) writes: > I tried your program on my system, a 512K CoCo3 with OS-9 Level 2, > the original Microware C Compiler and the Dev Pack Ramdisk. Clue 1: The program worked just fine on my floppy disk. Clue 2: Y'all both had used the DevPak ramdisk for testing. Not well-known fact: OS-9 also checks the device descriptor M$Mode setting. So my immediate thought was that this capability mode byte in the /R0 device descriptor wasn't fully turned on. And yep, it wasn't. Check the byte at offset $0D in your /R0 descriptor. It is $BF now... which means the shareable attribute is turned off. Change it to $FF, reverify, reboot, and I think all should be fine. > I'm writing a UNIX like ln(1) {thats a link} command for my CoCo to test > to see if the file manager respects the link byte in the file header > attribute. Yep, it does. Looking forward to your link command! And PS to Zack: thanks for the needed push :-). cheers - kevin