BJ> Squish places files in the outbound area in the 
 BJ> current setup with a umask of 600 instead of 660, 
 BJ> which then hangs BinkD from being able to properly 
 BJ> send outbound files.  Reception by BinkD and 
 BJ> processing by Squish is working.  So, I need to 
 BJ> change the umask for squish to 660, probably by 
 BJ> burring how squish is run under a shell script..... 
 BJ>  Or finding a rc file that is currently setting the 
 BJ> umask to 600 and change that to 660 for the account 
 BJ> squish is running under....
 
It's not the umask which is the problem -- it's actually the permissions
maximus uses to create the files. A subtle difference -- here's how it
works: 
 
 - umask is inherited from parent pid
 - the shell's umask can be changed with the umask built-in; e.g.
"umask 002"
 - The c library function to change/read the umask is umask()
 - When a file is created (e.g. with open), the permissions passed to
   open are NANDed with the umask, and the resulting number is used
   for the mode
 - File modes (permissions) and umasks are octal numbers. Each digit is
   three bits.
 
I intend to have maximus running with umask 002; so if maximus tryies to
create a file with permissions 0666, the umask will coerce that to 0664
during the open call. (The default umask on most unices is 022).
 
The problem right now is that scott opens all files 0600 (via I_ macros).
What I will likely do to correct the situation is to modify sopen() to to
detect when ((mode & 0077) == 0) and mode |= (mode & 0700 >>
3) | (mode & 0700 >> 6), then let the umask take care of removing
permissions. So, in effect, most of scott's open calls would wind up
creating rw-rw-r-- files when he asks for rw-------; similarly, if he asks
for r-------- we'll get r--r--r--, and if a later programmer asks
explicitly for rw-rw--- it will stay that way.
 
Oh, don't take that code verbatim, I think I missed some brackets.
 
Wes

--- Maximus/2 3.01