zambotti@wpowz.enet.dec.com (Walter Zambotti DEC) (06/11/91)
Hi there,
I having a small problem with the open() system call.
I'm using a CoCo III OS9 Lvl 2 with the level 1 C compiler.
When I open a file with the open mode OR'd with 0x40 (64 dec) which is
supposed to be the shareable attribute. The disk loses all directory
information and I affectatively wipe out my entire disk. This is even
the case regardless of the file I open (dir or normal file).
Now I have been testing this code on the Tandy Developement pack RAMDISK
(/r0) and this could possibly be just the ramdisk driver screwing up.
Of course I'm not game to try this on my normal disk as this would be
silly.
Anyone care to comment?
Here is my test code :
--------------------------tstmod.c-----------------------------
/* tstmod.c
example (open file with read/write/shareable modes) :
tstmod myfile 67
*/
main(argcnt, argval)
int argcnt ;
char *argval[] ;
{
int file ;
extern int errno ;
if(argcnt != 3) {
writeln(1, "tstmod file/dir open_mode\n", 80) ;
exit(0) ;
}
if((file = open(argval[1], atoi(argval[2]))) == -1) {
writeln(1, "bad file mode\n", 80) ;
exit(errno) ;
}
else {
writeln(1, "file mode ok!\n", 80) ;
}
close(file) ;
}session@seq.uncwil.edu (Zack C. Sessions) (06/12/91)
Wow, have you ever found a strange one!!
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. The
only possible difference is that I am using the Kreider Lib, but
I would be surprised to find that Carl's open() function would work
any different from the stock version. But it does!!
First off, it is my understanding that the s attribute is not the
"sharable" attribute, but the "single-user" attribute. According to
the Tech Ref, if this bit is on in the file's attribute mask, then
only one process can have an active path to it at one time. It also
goes on to state that you can specify this bit on during the Open
call to temporarily dis-allow any other access as long as you have
it opened that way.
Only thing is, the second method does not appear to work!! While I
cannot get the program to successfully open a file or directory
with the single user bit on, though, it doesn't trash my disk.
Files and directories are all still there and readable, but the
program does return an Error 203, Illegal mode!! No ownership
problems, since all is being done from userid 0.
So, basically I can't say what is happening to you except that I
cannot get the single-user access bit to work either, but it doesn't
trash the file system on the disk I test it with.
Maybe Kev will see this and respond!
Zack Sessions
session@seq.uncwil.edu
^^^
|
+---> Note: username is session, not sessions. Not my fault, ask
my SysAdmin about it!!zambotti@wpowz.enet.dec.com (Walter Zambotti DEC) (06/12/91)
Hi Zack,
thanks for the conformation. I get error 203 as well.
It seems that error 203 isn't liked very much the RAM disk driver which
leaves some of its internal device driver variable storage area out of
wack. Therefore rendering the RAM disk
unuseable until the next reboot (which obviously destroys the RAM
disk).
I'll create a new floppy and see if the error duplicates itself on one
of those.
The shareable bit (single use bit) is incorrectly described in the
manual it states that it allows sharing on the file. Wr..ooOOoo..ng!!!
It does the opposite like you said.
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.
I need to open directories and want to make sure that no one else opens
the directory while I do.
Hense the use of the single user bit.
Walterekuns@kilroy.chi.il.us (Eddie Kuns) (06/12/91)
zambotti@wpowz.enet.dec.com (Walter Zambotti DEC) writes: >I having a small problem with the open() system call. > >I'm using a CoCo III OS9 Lvl 2 with the level 1 C compiler. > >When I open a file with the open mode OR'd with 0x40 (64 dec) which is >supposed to be the shareable attribute. The disk loses all directory >information and I affectatively wipe out my entire disk. This is even >the case regardless of the file I open (dir or normal file). I've gotten this to work, as desired. As Zack, I'm using Carl Kreider's C library. Here is a short example: #include <modes.h> .... /* open the active file in non-sharable mode, read-write */ activepath = open(NGROUPS, S_IREAD | S_IWRITE | S_ISHARE); if (activepath == 0) { printf("readactive: can't open active file\n"); exit(0); } And this code works. (Other processes who open the file sleep until this process closes the file. They then awaken and can open the file.) I also use the Dev Sys RAM Disk, and haven't noticed any weird behavior with it. (The file I open above is not on the RAM disk.) My suggestion: If you're not using Carl Kreider's C library, you should get it. It may fix the above problem; it is much more capable, faster, and smaller.
kdarling@hobbes.catt.ncsu.edu (Kevin Darling) (06/12/91)
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 <kdarling@catt.ncsu.edu>
reising@colsw3.enet.dec.com (new to Ultrix) (06/12/91)
In article <43@kilroy.chi.il.us>, ekuns@kilroy.chi.il.us (Eddie Kuns) writes: |>From: ekuns@kilroy.chi.il.us (Eddie Kuns) |>Subject: Re: open() + sharable file = no disk |>Date: Wed, 12 Jun 91 04:49:47 GMT-12303291:44 |> |>zambotti@wpowz.enet.dec.com (Walter Zambotti DEC) writes: |> |>#include <modes.h> |> |> .... |> |> /* open the active file in non-sharable mode, read-write */ |> activepath = open(NGROUPS, S_IREAD | S_IWRITE | S_ISHARE); |> if (activepath == 0) -----------------> ^^^-- should it be (activepath < 0) /* or == -1 */ ? |> { printf("readactive: can't open active file\n"); |> exit(0); |> } |> |>And this code works. (Other processes who open the file sleep until |>this process closes the file. They then awaken and can open the file.) |> |>I also use the Dev Sys RAM Disk, and haven't noticed any weird behavior |>with it. (The file I open above is not on the RAM disk.) |> |>My suggestion: If you're not using Carl Kreider's C library, you should |>get it. It may fix the above problem; it is much more capable, |>faster, and smaller. |> /jr -- ###################################################################### Josef Reisinger (Software Quality never goes out of style...) Digital Equipment Corporation D-5000 Koeln Stolberger Strasse reisinger@col01.enet.dec.com ! VAX/VMS via USA ...unido!decum!col01.enet!reisinger ! VAX/VMS in EUROPE ######################################################################
session@seq.uncwil.edu (Zack C. Sessions) (06/13/91)
kdarling@hobbes.catt.ncsu.edu (Kevin Darling) writes: >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. I found that fact mentioned in the tech ref and checked that byte and it was, as you said, $BF, I misterpeted that as being what it SHOULD have been! I now understand what it DOES mean! Thanks. >Yep, it does. Looking forward to your link command! And PS to Zack: >thanks for the needed push :-). No problemo! btw, my MM/1 will be shipping this week!! Zack Sessions session@seq.uncwil.edu
zambotti@wpowz.enet.dec.com (Walter Zambotti DEC) (06/13/91)
Hi guys, nothing like a bug to get the blood stiring. I checked the program on a floppy and low and behold I found it works ok. Which confirms what you have already found out. I'll patch my /r0 descriptor and recheck the program. I'm pretty close to finishing the ln(1) command just some debugging to do now! You wont believe how much checking has to be done in order to create this link. Here is a brief overview : ln existing_file/dir new_file/dir does existing_file exist ? does new_file not-exist ? are both existing_file and new_file on the same device ? (cant link across disks!) if existing_file is a file then if existing_file contains a directory path then open directory portion of path else open . endif else must be directory open directory read second 32 byte entry (which is .. ) open .. endif search for existing_file entry in directory extract header sector lsn open raw device and read header sector lsn extract the link count and bump by one don't write back yet if new_file contains directory path then open directory portion of path else open . endif search in directory for empty entry if no empty entry then seek to end of file+1 endif write new entry with existing_file header sector lsn if write succeed then write back header sector now if write failed then erase new entry from directory endif endif done The current version is quit large about 8k. It has every line of code checked for error conditions which I feel is important until I start to trust links on OS9. Links are excellent but if you dont get them wrong it would be easy to screw up a disk quite quickly. The moment I get it going I'll release the source and then start stream lining. see ya round like a beach ball, Walter
bcwhite@crocus.waterloo.edu () (06/13/91)
Actually, rebooting the CoCo doesn't have to lose the ramdisk. I use KD's "Rammer" and have my startup set so that the Ram Disk is QUARANTEED to get the same ram (that no other statup program uses) each boot. Then before I call "Format" I call a little program I wrote to read LSN0 from the ram disk and compare it to a copy I kept of the hard drive. If they match, and a "dir -e" executes on '/r0' then I assume no problems and leave the ram disk intact. Otherwise I reformat it.
zambotti@wpowz.enet.dec.com (Walter Zambotti DEC) (06/14/91)
Hi there again guys, Looks like the Tandy Developement Pack RAM disk driver is buggy. >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. Well I tried this and it doesn't work. It seems that the ram driver incorrectly copies this byte into the file permissions byte of the /r0 directory file header. So that when you do this : dir /r0 error 253 (non-sharable file busy) this is definitely incorrect. The /r0 (or root) directory of every disk has its own file header with its own file permissions attribute byte. It is incorrect for the initialization routine of the ram driver to copy the disk attribute byte into file attribute byte of the file header of the /r0 directory. Even though the above error is received when a dir is performed upon /r0 it is still possible to create delete and every else on this now non-sharable disk??? This must be a bug! You can either use it or not use it. Non-sharable shouldn't just effect the dir command it should effect any type of access. Anyway my tstmod program still fails with error 203 (cannot perform specified function) when run with mode 64+?. And after running tstmod any use on the /r0 device returns the error 241 (sector number out of range). It looks like its time to disassemble the ram driver. I'll have a crack at this but don't hold your breath waiting as I dont have much experience in this sort of thing. I'll continue to write the ln(1) command but it's not going to work on the Tandy ram disk for a while. regards, Walter
blarson@blars (06/14/91)
In article <1991Jun13.014701.22156@tkou02.enet.dec.com> zambotti@wpowz.enet.dec.com (Walter Zambotti DEC) writes: >I'm pretty close to finishing the ln(1) command just some debugging to do now! Did you try the existing ones for os9 first? >You wont believe how much checking has to be done in order to create >this link. Actually, those of us that have already done one would. You seem to have left out the check for legal file names. Also don't forget the locks to make sure nothing changes between when you check and when you do the writes. >The current version is quit large about 8k. Mine for osk was written in C, includes mv, and the executable is 6446 bytes long. > It has every line of code >checked for error conditions which I feel is important until I start to >trust links on OS9. Of course all possible errors should be checked for. Please don't let me know if you decided to take out the error checking code. -- blarson@usc.edu C news and rn for os9/68k! -- Bob Larson (blars) blarson@usc.edu usc!blarson Hiding differences does not make them go away. Accepting differences makes them unimportant.
Sepp@ppcger.ppc.sub.org (Josef Wolf) (06/14/91)
zambotti@wpowz.enet.dec.com (Walter Zambotti DEC) writes: [ ... ] ] Links are excellent but if you dont get them wrong it would be easy to ] screw up a disk quite quickly. The moment I get it going I'll release ] the source and then start stream lining. Don't forget: the link have to be done atomar! _No_ other process should be able to access the disk while you are doing the linking! regards Sepp | Josef Wolf, Germersheim, Germany | +49 7274 8047 -24 Hours- (call me :-) | | sepp@ppcger.ppc.sub.org | +49 7274 8048 -24 Hours- | | ...!ira.uka.de!smurf!ppcger!sepp | +49 7274 8967 18:00-8:00, Sa + Su 24h | | Die Welt ist schoen, so schoen! | all lines 300/1200/2400 bps 8n1 | | Was ich nicht weiss, macht mich nicht heiss. Drum bleib ich immer heiter! |