177 lines
		
	
	
		
			6.5 KiB
		
	
	
	
		
			HTML
		
	
	
	
	
	
			
		
		
	
	
			177 lines
		
	
	
		
			6.5 KiB
		
	
	
	
		
			HTML
		
	
	
	
	
	
| <!--
 | |
| Copyright (c) 2000, 2001, 2002, 2003, 2004, 2005, 2008, 2009, 2013
 | |
| 	The President and Fellows of Harvard College.
 | |
| 
 | |
| Redistribution and use in source and binary forms, with or without
 | |
| modification, are permitted provided that the following conditions
 | |
| are met:
 | |
| 1. Redistributions of source code must retain the above copyright
 | |
|    notice, this list of conditions and the following disclaimer.
 | |
| 2. Redistributions in binary form must reproduce the above copyright
 | |
|    notice, this list of conditions and the following disclaimer in the
 | |
|    documentation and/or other materials provided with the distribution.
 | |
| 3. Neither the name of the University nor the names of its contributors
 | |
|    may be used to endorse or promote products derived from this software
 | |
|    without specific prior written permission.
 | |
| 
 | |
| THIS SOFTWARE IS PROVIDED BY THE UNIVERSITY AND CONTRIBUTORS ``AS IS'' AND
 | |
| ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
 | |
| IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
 | |
| ARE DISCLAIMED.  IN NO EVENT SHALL THE UNIVERSITY OR CONTRIBUTORS BE LIABLE
 | |
| FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
 | |
| DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
 | |
| OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
 | |
| HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
 | |
| LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
 | |
| OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
 | |
| SUCH DAMAGE.
 | |
| -->
 | |
| <html>
 | |
| <head>
 | |
| <title>open</title>
 | |
| <link rel="stylesheet" type="text/css" media="all" href="../man.css">
 | |
| </head>
 | |
| <body bgcolor=#ffffff>
 | |
| <h2 align=center>open</h2>
 | |
| <h4 align=center>OS/161 Reference Manual</h4>
 | |
| 
 | |
| <h3>Name</h3>
 | |
| <p>
 | |
| open - open a file
 | |
| </p>
 | |
| 
 | |
| <h3>Library</h3>
 | |
| <p>
 | |
| Standard C Library (libc, -lc)
 | |
| </p>
 | |
| 
 | |
| <h3>Synopsis</h3>
 | |
| <p>
 | |
| <tt>#include <unistd.h></tt><br>
 | |
| <tt>#include <fcntl.h></tt><br>
 | |
| <br>
 | |
| <tt>int</tt><br>
 | |
| <tt>open(const char *</tt><em>filename</em><tt>,
 | |
| int </tt><em>flags</em><tt>);</tt><br>
 | |
| <tt>int</tt><br>
 | |
| <tt>open(const char *</tt><em>filename</em><tt>, int </tt><em>flags</em><tt>,
 | |
| mode_t </tt><em>mode</em><tt>);</tt><br>
 | |
| </p>
 | |
| 
 | |
| <h3>Description</h3>
 | |
| <p>
 | |
| <tt>open</tt> opens the file, device, or other kernel object named by
 | |
| the pathname <em>filename</em>. The <em>flags</em> argument specifies
 | |
| how to open the file. The optional <em>mode</em> argument provides the
 | |
| file permissions to use and is only meaningful in Unix, or if you
 | |
| choose to implement Unix-style security later on. it can be ignored in
 | |
| OS/161.
 | |
| </p>
 | |
| 
 | |
| <p>
 | |
| The flags argument should consist of one of
 | |
| <table width=90%>
 | |
| <tr><td width=5% rowspan=3> </td>
 | |
|     <td width=30%>O_RDONLY</td>	<td>Open for reading only.</td></tr>
 | |
| <tr><td>O_WRONLY</td>		<td>Open for writing only.</td></tr>
 | |
| <tr><td>O_RDWR</td>		<td>Open for reading and writing.</td></tr>
 | |
| </table>
 | |
| </p>
 | |
| 
 | |
| <p>
 | |
| It may also have any of the following flags OR'd in:
 | |
| <table width=90%>
 | |
| <tr><td width=5% rowspan=4> </td>
 | |
|     <td width=20%>O_CREAT</td>
 | |
| 			<td>Create the file if it doesn't exist.</td></tr>
 | |
| <tr><td>O_EXCL</td>	<td>Fail if the file already exists.</td></tr>
 | |
| <tr><td>O_TRUNC</td>	<td>Truncate the file to length 0 upon open.</td></tr>
 | |
| <tr><td>O_APPEND</td>	<td>Open the file in append mode.</td></tr>
 | |
| </table>
 | |
| O_EXCL is only meaningful if O_CREAT is also used.
 | |
| </p>
 | |
| 
 | |
| <p>
 | |
| O_APPEND causes all writes to the file to occur at the end of file, no
 | |
| matter what gets written to the file by whoever else, including
 | |
| concurrently. (This functionality may be optional; consult your
 | |
| course's assignments.)
 | |
| </p>
 | |
| 
 | |
| <p>
 | |
| <tt>open</tt> returns a file handle suitable for passing to
 | |
| <A HREF=read.html>read</A>,
 | |
| <A HREF=write.html>write</A>,
 | |
| <A HREF=close.html>close</A>,
 | |
| etc. This file handle must be greater than or equal to zero.  Note
 | |
| that file handles 0 (STDIN_FILENO), 1 (STDOUT_FILENO), and 2
 | |
| (STDERR_FILENO) are used in special ways and are typically assumed by
 | |
| user-level code to always be open.
 | |
| </p>
 | |
| 
 | |
| <p>
 | |
| If you are implementing symbolic links, there are some additional
 | |
| points to take note of. If <em>filename</em> refers to a symbolic
 | |
| link, that link does not point to an existing object, and O_CREAT is
 | |
| specified, a new file is created <i>at the name the link points
 | |
| to</i>. However, if in this case both O_CREAT and O_EXCL are
 | |
| specified, <tt>open</tt> fails with EEXIST. These semantics are a
 | |
| nuisance to implement but important for correct functioning.
 | |
| </p>
 | |
| 
 | |
| <p>
 | |
| <tt>open</tt> (like all system calls) should be atomic. It is
 | |
| important for the handling of O_EXCL in the destination directory to
 | |
| be atomic. Note, however, that in practice looking up directories that
 | |
| contain <tt>..</tt> is usually not quite atomic.
 | |
| </p>
 | |
| 
 | |
| <h3>Return Values</h3>
 | |
| <p>
 | |
| On success, <tt>open</tt> returns a nonnegative file handle. On error,
 | |
| -1 is returned, and <A HREF=errno.html>errno</A> is set according to
 | |
| the error encountered.
 | |
| </p>
 | |
| 
 | |
| <h3>Errors</h3>
 | |
| <p>
 | |
| The following error codes should be returned under the conditions
 | |
| given. Other error codes may be returned for other cases not
 | |
| mentioned here.
 | |
| 
 | |
| <table width=90%>
 | |
| <tr><td width=5% rowspan=15> </td>
 | |
|     <td width=10% valign=top>ENODEV</td>
 | |
| 				<td>The device prefix of <em>filename</em> did
 | |
| 				not exist.</td></tr>
 | |
| <tr><td valign=top>ENOTDIR</td>	<td>A non-final component of <em>filename</em>
 | |
| 				was not a directory.</td></tr>
 | |
| <tr><td valign=top>ENOENT</td>	<td>A non-final component of <em>filename</em>
 | |
| 				did not exist.</td></tr>
 | |
| <tr><td valign=top>ENOENT</td>	<td>The named file does not exist, and O_CREAT
 | |
| 				was not specified.</td></tr>
 | |
| <tr><td valign=top>EEXIST</td>	<td>The named file exists, and O_EXCL was
 | |
| 				specified.</td></tr>
 | |
| <tr><td valign=top>EISDIR</td>	<td>The named object is a directory, and it
 | |
| 				was to be opened for writing.</td></tr>
 | |
| <tr><td valign=top>EMFILE</td>	<td>The process's file table was full, or a
 | |
| 				process-specific limit on open files
 | |
| 				was reached.</td></tr>
 | |
| <tr><td valign=top>ENFILE</td>	<td>The system file table is full, if such a
 | |
| 				thing exists, or a system-wide limit
 | |
| 				on open files was reached.</td></tr>
 | |
| <tr><td valign=top>ENXIO</td>	<td>The named object is a block device with no
 | |
| 				filesystem mounted on it.</td></tr>
 | |
| <tr><td valign=top>ENOSPC</td>	<td>The file was to be created, and the
 | |
| 				filesystem involved is full.</td></tr>
 | |
| <tr><td valign=top>EINVAL</td>	<td><em>flags</em> contained invalid
 | |
| 				values.</td></tr>
 | |
| <tr><td valign=top>EIO</td>	<td>A hard I/O error occurred.</td></tr>
 | |
| <tr><td valign=top>EFAULT</td>	<td><em>filename</em> was an invalid
 | |
| 				pointer.</td></tr>
 | |
| </table>
 | |
| </p>
 | |
| 
 | |
| </body>
 | |
| </html>
 |