open.html

posix标准英文,html格式

<b>off_t</b>.</dd>

<dt>[EROFS]</dt>

<dd>The named file resides on a read-only file system and either O_WRONLY, O_RDWR, O_CREAT (if the file does not exist), or O_TRUNC
is set in the <i>oflag</i> argument.</dd>
</dl>

<p>The <i>open</i>() function may fail if:</p>

<dl compact>
<dt>[EAGAIN]</dt>

<dd><sup>[<a href="javascript:open_code('XSI')">XSI</a>]</sup> <img src="../images/opt-start.gif" alt="[Option Start]" border="0">
The <i>path</i> argument names the slave side of a pseudo-terminal device that is locked. <img src="../images/opt-end.gif" alt=
"[Option End]" border="0"></dd>

<dt>[EINVAL]</dt>

<dd>The value of the <i>oflag</i> argument is not valid.</dd>

<dt>[ELOOP]</dt>

<dd>More than {SYMLOOP_MAX} symbolic links were encountered during resolution of the <i>path</i> argument.</dd>

<dt>[ENAMETOOLONG]</dt>

<dd>
As a result of encountering a symbolic link in resolution of the <i>path</i> argument, the length of the substituted pathname
string exceeded {PATH_MAX}.</dd>

<dt>[ENOMEM]</dt>

<dd><sup>[<a href="javascript:open_code('XSR')">XSR</a>]</sup> <img src="../images/opt-start.gif" alt="[Option Start]" border="0">
The <i>path</i> argument names a STREAMS file and the system is unable to allocate resources. <img src="../images/opt-end.gif" alt=
"[Option End]" border="0"></dd>

<dt>[ETXTBSY]</dt>

<dd>The file is a pure procedure (shared text) file that is being executed and <i>oflag</i> is O_WRONLY or O_RDWR.</dd>
</dl>
</blockquote>

<hr>
<div class="box"><em>The following sections are informative.</em></div>

<h4><a name="tag_03_410_06"></a>EXAMPLES</h4>

<blockquote>
<h5><a name="tag_03_410_06_01"></a>Opening a File for Writing by the Owner</h5>

<p>The following example opens the file <b>/tmp/file</b>, either by creating it (if it does not already exist), or by truncating
its length to 0 (if it does exist). In the former case, if the call creates a new file, the access permission bits in the file mode
of the file are set to permit reading and writing by the owner, and to permit reading only by group members and others.</p>

<p>If the call to <i>open</i>() is successful, the file is opened for writing.</p>

<pre>
<tt>#include &lt;fcntl.h&gt;
...
int fd;
mode_t mode = S_IRUSR | S_IWUSR | S_IRGRP | S_IROTH;
char *filename = "/tmp/file";
...
fd = open(filename, O_WRONLY | O_CREAT | O_TRUNC, mode);
...
</tt>
</pre>

<h5><a name="tag_03_410_06_02"></a>Opening a File Using an Existence Check</h5>

<p>The following example uses the <i>open</i>() function to try to create the <b>LOCKFILE</b> file and open it for writing. Since
the <i>open</i>() function specifies the O_EXCL flag, the call fails if the file already exists. In that case, the program assumes
that someone else is updating the password file and exits.</p>

<pre>
<tt>#include &lt;fcntl.h&gt;
#include &lt;stdio.h&gt;
#include &lt;stdlib.h&gt;
<br>
#define LOCKFILE "/etc/ptmp"
...
int pfd; /* Integer for file descriptor returned by open() call. */
...
if ((pfd = open(LOCKFILE, O_WRONLY | O_CREAT | O_EXCL,
    S_IRUSR | S_IWUSR | S_IRGRP | S_IROTH)) == -1)
{
    fprintf(stderr, "Cannot open /etc/ptmp. Try again later.\n");
    exit(1);
}
...
</tt>
</pre>

<h5><a name="tag_03_410_06_03"></a>Opening a File for Writing</h5>

<p>The following example opens a file for writing, creating the file if it does not already exist. If the file does exist, the
system truncates the file to zero bytes.</p>

<pre>
<tt>#include &lt;fcntl.h&gt;
#include &lt;stdio.h&gt;
#include &lt;stdlib.h&gt;
<br>
#define LOCKFILE "/etc/ptmp"
...
int pfd;
char filename[PATH_MAX+1];
...
if ((pfd = open(filename, O_WRONLY | O_CREAT | O_TRUNC,
    S_IRUSR | S_IWUSR | S_IRGRP | S_IROTH)) == -1)
{
    perror("Cannot open output file\n"); exit(1);
}
...
</tt>
</pre>
</blockquote>

<h4><a name="tag_03_410_07"></a>APPLICATION USAGE</h4>

<blockquote>
<p>None.</p>
</blockquote>

<h4><a name="tag_03_410_08"></a>RATIONALE</h4>

<blockquote>
<p>Except as specified in this volume of IEEE&nbsp;Std&nbsp;1003.1-2001, the flags allowed in <i>oflag</i> are not
mutually-exclusive and any number of them may be used simultaneously.</p>

<p>Some implementations permit opening FIFOs with O_RDWR. Since FIFOs could be implemented in other ways, and since two file
descriptors can be used to the same effect, this possibility is left as undefined.</p>

<p>See <a href="getgroups.html"><i>getgroups</i>()</a> about the group of a newly created file.</p>

<p>The use of <i>open</i>() to create a regular file is preferable to the use of <a href=
"../functions/creat.html"><i>creat</i>()</a>, because the latter is redundant and included only for historical reasons.</p>

<p>The use of the O_TRUNC flag on FIFOs and directories (pipes cannot be <i>open</i>()-ed) must be permissible without unexpected
side effects (for example, <a href="../functions/creat.html"><i>creat</i>()</a> on a FIFO must not remove data). Since terminal
special files might have type-ahead data stored in the buffer, O_TRUNC should not affect their content, particularly if a program
that normally opens a regular file should open the current controlling terminal instead. Other file types, particularly
implementation-defined ones, are left implementation-defined.</p>

<p>IEEE&nbsp;Std&nbsp;1003.1-2001 permits [EACCES] to be returned for conditions other than those explicitly listed.</p>

<p>The O_NOCTTY flag was added to allow applications to avoid unintentionally acquiring a controlling terminal as a side effect of
opening a terminal file. This volume of IEEE&nbsp;Std&nbsp;1003.1-2001 does not specify how a controlling terminal is acquired, but
it allows an implementation to provide this on <i>open</i>() if the O_NOCTTY flag is not set and other conditions specified in the
Base Definitions volume of IEEE&nbsp;Std&nbsp;1003.1-2001, <a href="../basedefs/xbd_chap11.html#tag_11">Chapter 11, General
Terminal Interface</a> are met. The O_NOCTTY flag is an effective no-op if the file being opened is not a terminal device.</p>

<p>In historical implementations the value of O_RDONLY is zero. Because of that, it is not possible to detect the presence of
O_RDONLY and another option. Future implementations should encode O_RDONLY and O_WRONLY as bit flags so that:</p>

<pre>
<tt>O_RDONLY | O_WRONLY == O_RDWR
</tt>
</pre>

<p>In general, the <i>open</i>() function follows the symbolic link if <i>path</i> names a symbolic link. However, the
<i>open</i>() function, when called with O_CREAT and O_EXCL, is required to fail with [EEXIST] if <i>path</i> names an existing
symbolic link, even if the symbolic link refers to a nonexistent file. This behavior is required so that privileged applications
can create a new file in a known location without the possibility that a symbolic link might cause the file to be created in a
different location.</p>

<p>For example, a privileged application that must create a file with a predictable name in a user-writable directory, such as the
user's home directory, could be compromised if the user creates a symbolic link with that name that refers to a nonexistent file in
a system directory. If the user can influence the contents of a file, the user could compromise the system by creating a new system
configuration or spool file that would then be interpreted by the system. The test for a symbolic link which refers to a
nonexisting file must be atomic with the creation of a new file.</p>

<p>The POSIX.1-1990 standard required that the group ID of a newly created file be set to the group ID of its parent directory or
to the effective group ID of the creating process. FIPS 151-2 required that implementations provide a way to have the group ID be
set to the group ID of the containing directory, but did not prohibit implementations also supporting a way to set the group ID to
the effective group ID of the creating process. Conforming applications should not assume which group ID will be used. If it
matters, an application can use <a href="../functions/chown.html"><i>chown</i>()</a> to set the group ID after the file is created,
or determine under what conditions the implementation will set the desired group ID.</p>
</blockquote>

<h4><a name="tag_03_410_09"></a>FUTURE DIRECTIONS</h4>

<blockquote>
<p>None.</p>
</blockquote>

<h4><a name="tag_03_410_10"></a>SEE ALSO</h4>

<blockquote>
<p><a href="chmod.html"><i>chmod</i>()</a>, <a href="close.html"><i>close</i>()</a>, <a href="creat.html"><i>creat</i>()</a>, <a
href="dup.html"><i>dup</i>()</a>, <a href="fcntl.html"><i>fcntl</i>()</a>, <a href="lseek.html"><i>lseek</i>()</a>, <a href=
"read.html"><i>read</i>()</a>, <a href="umask.html"><i>umask</i>()</a>, <a href="unlockpt.html"><i>unlockpt</i>()</a>, <a href=
"write.html"><i>write</i>()</a>, the Base Definitions volume of IEEE&nbsp;Std&nbsp;1003.1-2001, <a href=
"../basedefs/fcntl.h.html"><i>&lt;fcntl.h&gt;</i></a>, <a href="../basedefs/sys/stat.h.html"><i>&lt;sys/stat.h&gt;</i></a>, <a
href="../basedefs/sys/types.h.html"><i>&lt;sys/types.h&gt;</i></a></p>
</blockquote>

<h4><a name="tag_03_410_11"></a>CHANGE HISTORY</h4>

<blockquote>
<p>First released in Issue 1. Derived from Issue 1 of the SVID.</p>
</blockquote>

<h4><a name="tag_03_410_12"></a>Issue 5</h4>

<blockquote>
<p>The DESCRIPTION is updated for alignment with the POSIX Realtime Extension and the POSIX Threads Extension.</p>

<p>Large File Summit extensions are added.</p>
</blockquote>

<h4><a name="tag_03_410_13"></a>Issue 6</h4>

<blockquote>
<p>In the SYNOPSIS, the optional include of the <a href="../basedefs/sys/types.h.html"><i>&lt;sys/types.h&gt;</i></a> header is
removed.</p>

<p>The following new requirements on POSIX implementations derive from alignment with the Single UNIX Specification:</p>

<ul>
<li>
<p>The requirement to include <a href="../basedefs/sys/types.h.html"><i>&lt;sys/types.h&gt;</i></a> has been removed. Although <a
href="../basedefs/sys/types.h.html"><i>&lt;sys/types.h&gt;</i></a> was required for conforming implementations of previous POSIX
specifications, it was not required for UNIX applications.</p>
</li>

<li>
<p>In the DESCRIPTION, O_CREAT is amended to state that the group ID of the file is set to the group ID of the file's parent
directory or to the effective group ID of the process. This is a FIPS requirement.</p>
</li>

<li>
<p>In the DESCRIPTION, text is added to indicate setting of the offset maximum in the open file description. This change is to
support large files.</p>
</li>

<li>
<p>In the ERRORS section, the [EOVERFLOW] condition is added. This change is to support large files.</p>
</li>

<li>
<p>The [ENXIO] mandatory error condition is added.</p>
</li>

<li>
<p>The [EINVAL], [ENAMETOOLONG], and [ETXTBSY] optional error conditions are added.</p>
</li>
</ul>

<p>The DESCRIPTION and ERRORS sections are updated so that items related to the optional XSI STREAMS Option Group are marked.</p>

<p>The following changes were made to align with the IEEE&nbsp;P1003.1a draft standard:</p>

<ul>
<li>
<p>An explanation is added of the effect of the O_CREAT and O_EXCL flags when the path refers to a symbolic link.</p>
</li>

<li>
<p>The [ELOOP] optional error condition is added.</p>
</li>
</ul>

<p>The DESCRIPTION is updated to avoid use of the term &quot;must&quot; for application requirements.</p>

<p>The DESCRIPTION of O_EXCL is updated in response to IEEE PASC Interpretation 1003.1c #48.</p>
</blockquote>

<div class="box"><em>End of informative text.</em></div>

<hr size="2" noshade>
<center><font size="2"><!--footer start-->
UNIX &reg; is a registered Trademark of The Open Group.<br>
POSIX &reg; is a registered Trademark of The IEEE.<br>
[ <a href="../mindex.html">Main Index</a> | <a href="../basedefs/contents.html">XBD</a> | <a href=
"../utilities/contents.html">XCU</a> | <a href="../functions/contents.html">XSH</a> | <a href="../xrat/contents.html">XRAT</a>
]</font></center>

<!--footer end-->
<hr size="2" noshade>
</body>
</html>