This version does not incorporate the suggestion that "the MPI_Open could
also return a warning in this case telling the user that the permissions
given in the info structure were ignored."
-terry
==============================================================
MPI_OPEN(comm, filename, amode, perm, info, fh)
...
IN perm [SAME] File permissions
...
int MPI_Open(MPI_Comm comm, char *filename, int amode, unsigned int perm,
MPI_Info info, MPI_File *fh)
...
If \mpiarg{amode} is set to \const{MPI\_CREATE}, the permissions to
be assigned to the file on creation can be specified in \mpiarg{perm}.
The value for \mpiarg{perm} may either be: any regular POSIX-style
permission (e.g. 0644); the special value \const{MPI\_PERM\_NULL},
which means use the default file permissions on the system; or the
special value \const{MPI\_PERM\_IN\_INFO}, which means the implementation
will look for the permission in the info structure. If
\const{MPI\_PERM\_IN\_INFO} is specified but the info structure
contains no permission spec, or the spec is not understood by the
implementation, the default permissions are used. Conversely, if
the permission parameter is {\bfnot} \const{MPI\_PERM\_IN\_INFO}
but the info structure {\bfdoes} supply a permission definition,
that definition will be ignored.
Rational
This keeps the implementation-dependent specification in the info
structure while handling the common case of POSIX-style permissions
simply. In the event of permission conflicts between the perm parameter
and info parameter, the conflict is resolved in favor of having the
most visible specification of the permissions take precedence over
whatever is given in the info structure.
End Rational