umask not preserved - a FORTRAN issue?

[Paul Neralich]

How could the execution of an HP-UX script file via a FORTRAN program not preserve an account's umask value?

For example, I have a HP-UX script that, when executed manually, produces a log file with the ">>" command. The log file has the expected permissions of 644 (the umask has been set to 022 in the account's .profile).

However, when the same HP-UX script is executed from a FORTRAN program under the same account, the log file produced has the default permissions 666. For troubleshooting purposes I modified the script to write out the umask and when run via FORTRAN program, it is reported as 00.

Even if the FORTRAN program uses a FORK and a child process to run the script, what I've learned about FORK is that it should preserve the umask.

I apologize for rather vague references to "A FORTRAN Program", but speaking theoretically - what might cause the umask set in the .profile of an account to be wiped out? I appreciate any help.

[Patrick Wallek]

I don't know what could cause the issue, but if you want to make sure the file gets created with 644 permissions, you could put a 'umask 022' statement in the script that is being called by the Fortran program.

[A. Clay Stephenson]

Ah, but you are making the assumption that the FORTRAN program doesn't do a umask(0000) itself before doing an open() or creat() system call.

[A. Clay Stephenson]

Since it does appear that the FORTRAN program does a umask(0000) before the system() function that invokes your shell shell, an explicit umask 022 in your script should solve the problem. Because the shell is executed as a child process in the system() function, umask will still remain 0000 in the parent FORTRAN process but nevertheless if the file is actually created via your script, the script's umask will prevail.

Note that ">>" will not affect the mode of the file if the file already exists.