From: CSBVAX::MRGATE!INFO-VAX-RELAY@KL.SRI.COM@SMTP 8-JUL-1988 19:36 To: ARISIA::EVERHART Subj: re: Weird behaviour of SYS$SETDFPROT Received: from Venus.YCC.Yale.Edu by KL.SRI.COM with TCP; Tue 3 May 88 09:06:40-PDT Date: Tue, 3 May 88 12:03 EST From: "Jerry Leichter (LEICHTER-JERRY@CS.YALE.EDU)" Subject: re: Weird behaviour of SYS$SETDFPROT To: STAM@HROEUR51.BITNET, INFO-VAX@KL.SRI.COM X-VMS-To: IN%"STAM@HROEUR51.BITNET",INFOVAX SYS$SETDFPROT is causing me troubles... I want to create a file from within an executable. This file has some default protection, but THAT protection is not the one I need, so I want to establish a new default protection for the file about to be created. The funny thing is, the system service tells me it has indeed set the new default value, but fopen uses the value as it was before starting the image. Whenever I run it again, it uses the value set in the PREVIOUS run. Actually, you are seeing a bizarre interaction between SETDFPROT and the Unix emulation functions in the VAX C RTL. Unix has an analogue to the default VMS file protection, the so-called umask value; this can be set by calling the umask() function. When you use any of the VAX C RTL functions to create a file, they specify a protection based on the current umask value. Since they hand RMS an explicit protection, RMS ignores the process default protec- tion. This leads various to odd behavior. For example, if you specify a default protection for a directory with a DEFAULT ACE on the directory file, files created in the directory using C programs will ignore it. What seems to be happening in your case is the following: When the C program starts up, the RTL reads the RMS default protection and sets an initial value for umask from that. You then call SYS$SETDFPROT, a fact the RTL is unaware of; it doesn't recompute the umask value. So, when you create a file with fopen(), the saved umask value - based on the old RMS default protection - is used. If you run the program again, the same thing happens - but by this time the RMS default protection is the one you set in your call, so IT gets used to build the umask value - and your next fopen() uses the value "left over" from the previous run. There is a simple work-around: After you call SYS$SETDFPROT, also call umask() to hand the same protection to the VAX C RTL. The major limitation is that Unix protections are a subset of VMS protections: There is no DELETE protection, and no SYSTEM access. The RTL gives SYSTEM the same access as OWNER and makes DELETE the same as WRITE. -- Jerry -------