Rajeev
> Date: Fri, 27 Sep 96 10:54:32 PDT
> From: trj@nimble.llnl.gov (Terry R. Jones)
> Sender: owner-mpi-io@mcs.anl.gov
> Precedence: bulk
>
>
> Here's the text for the MPI_Open permissions proposal from John May and me.
>
> 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