126 lines
		
	
	
		
			4.5 KiB
		
	
	
	
		
			HTML
		
	
	
	
	
	
			
		
		
	
	
			126 lines
		
	
	
		
			4.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>getdirentry</title>
 | |
| <link rel="stylesheet" type="text/css" media="all" href="../man.css">
 | |
| </head>
 | |
| <body bgcolor=#ffffff>
 | |
| <h2 align=center>getdirentry</h2>
 | |
| <h4 align=center>OS/161 Reference Manual</h4>
 | |
| 
 | |
| <h3>Name</h3>
 | |
| <p>
 | |
| getdirentry - read filename from directory
 | |
| </p>
 | |
| 
 | |
| <h3>Library</h3>
 | |
| <p>
 | |
| Standard C Library (libc, -lc)
 | |
| </p>
 | |
| 
 | |
| <h3>Synopsis</h3>
 | |
| <p>
 | |
| <tt>#include <unistd.h></tt><br>
 | |
| <br>
 | |
| <tt>int</tt><br>
 | |
| <tt>getdirentry(int </tt><em>fd</em><tt>, char *</tt><em>buf</em><tt>,
 | |
| size_t </tt><em>buflen</em><tt>);</tt>
 | |
| </p>
 | |
| 
 | |
| <h3>Description</h3>
 | |
| <p>
 | |
| <tt>getdirentry</tt> retrieves the next filename from a directory
 | |
| referred to by the file handle <em>filehandle</em>. The name is stored
 | |
| in <em>buf</em>, an area of size <em>buflen</em>. The length of of the
 | |
| name actually found is returned.
 | |
| </p>
 | |
| 
 | |
| <p>
 | |
| Note: this call behaves like read() - the name stored in <em>buf</em>
 | |
| is not null-terminated.
 | |
| </p>
 | |
| 
 | |
| <p>
 | |
| Which filename is the "next" is chosen based on the seek pointer
 | |
| associated with the file handle. The meaning of the seek pointer on a
 | |
| directory is defined by the filesystem in use and should not be
 | |
| interpreted - the only ways in which <A HREF=lseek.html>lseek</A>
 | |
| should be used are with SEEK_SET and an offset previously returned by
 | |
| lseek, or with any of SEEK_SET, SEEK_CUR, or SEEK_EOF with an offset
 | |
| of 0.
 | |
| </p>
 | |
| 
 | |
| <p>
 | |
| <tt>getdirentry</tt> (like all system calls) should be atomic. In this
 | |
| case this means that each <tt>getdirentry</tt> call should return a
 | |
| name that was in the directory at the point in time when the call
 | |
| happened relative to other calls. <tt>getdirentry</tt> should never
 | |
| return names that have only been partially written or that have been
 | |
| partially erased.
 | |
| Note that the kernel is not obliged to (and generally cannot) make the
 | |
| getdirentry call atomic with respect to other threads in the same
 | |
| process accessing the transfer buffer during the operation.
 | |
| </p>
 | |
| 
 | |
| <p>
 | |
| In general it is desirable for directory iteration to be stable; that
 | |
| is, opening a directory and reading it should yield a consistent
 | |
| snapshot of the directory state. Implementing this is a nuisance in
 | |
| general, and is worse in OS/161 since the system call we have can only
 | |
| return one name at a time. Therefore, it isn't required by default.
 | |
| (However, always check your course materials for the official word,
 | |
| just in case.)
 | |
| </p>
 | |
| 
 | |
| <h3>Return Values</h3>
 | |
| <p>
 | |
| On success, <tt>getdirentry</tt> returns the length of the name
 | |
| transferred.  On error, -1 is returned, and
 | |
| <A HREF=errno.html>errno</A> is set according to the error
 | |
| encountered.
 | |
| </p>
 | |
| 
 | |
| <h3>Errors</h3>
 | |
| 
 | |
| <table width=90%>
 | |
| <tr><td width=5% rowspan=4> </td>
 | |
|     <td width=10% valign=top>EBADF</td>
 | |
| 				<td><em>fd</em> is not a valid file
 | |
| 				handle.</td></tr>
 | |
| <tr><td valign=top>ENOTDIR</td>	<td><em>fd</em> does not refer to a
 | |
| 				directory.</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>buf</em> points to an invalid
 | |
| 				address.</td></tr>
 | |
| </table>
 | |
| 
 | |
| </body>
 | |
| </html>
 |