+<!-- Copyright (C) 2003 Red Hat, Inc. -->
+<!-- This material may be distributed only subject to the terms -->
+<!-- and conditions set forth in the Open Publication License, v1.0 -->
+<!-- or later (the latest version is presently available at -->
+<!-- http://www.opencontent.org/openpub/). -->
+<!-- Distribution of the work or derivative of the work in any -->
+<!-- standard (paper) book form is prohibited unless prior -->
+<!-- permission is obtained from the copyright holder. -->
+<HTML
+><HEAD
+><TITLE
+>Directories</TITLE
+><meta name="MSSmartTagsPreventParsing" content="TRUE">
+<META
+NAME="GENERATOR"
+CONTENT="Modular DocBook HTML Stylesheet Version 1.76b+
+"><LINK
+REL="HOME"
+TITLE="eCos Reference Manual"
+HREF="ecos-ref.html"><LINK
+REL="UP"
+TITLE="File System Support Infrastructure"
+HREF="fileio.html"><LINK
+REL="PREVIOUS"
+TITLE="File Table"
+HREF="fileio-file-table.html"><LINK
+REL="NEXT"
+TITLE="Synchronization"
+HREF="fileio-synchronization.html"></HEAD
+><BODY
+CLASS="CHAPTER"
+BGCOLOR="#FFFFFF"
+TEXT="#000000"
+LINK="#0000FF"
+VLINK="#840084"
+ALINK="#0000FF"
+><DIV
+CLASS="NAVHEADER"
+><TABLE
+SUMMARY="Header navigation table"
+WIDTH="100%"
+BORDER="0"
+CELLPADDING="0"
+CELLSPACING="0"
+><TR
+><TH
+COLSPAN="3"
+ALIGN="center"
+>eCos Reference Manual</TH
+></TR
+><TR
+><TD
+WIDTH="10%"
+ALIGN="left"
+VALIGN="bottom"
+><A
+HREF="fileio-file-table.html"
+ACCESSKEY="P"
+>Prev</A
+></TD
+><TD
+WIDTH="80%"
+ALIGN="center"
+VALIGN="bottom"
+></TD
+><TD
+WIDTH="10%"
+ALIGN="right"
+VALIGN="bottom"
+><A
+HREF="fileio-synchronization.html"
+ACCESSKEY="N"
+>Next</A
+></TD
+></TR
+></TABLE
+><HR
+ALIGN="LEFT"
+WIDTH="100%"></DIV
+><DIV
+CLASS="CHAPTER"
+><H1
+><A
+NAME="FILEIO-DIRECTORIES">Chapter 23. Directories</H1
+><P
+>Filesystem operations all take a directory pointer as one of their
+arguments. A directory pointer is an opaque handle managed by the
+filesystem. It should encapsulate a reference to a specific directory
+within the filesystem. For example, it may be a pointer to the data
+structure that represents that directory (such as an inode), or a
+pointer to a pathname for the directory.</P
+><P
+>The <TT
+CLASS="FUNCTION"
+>chdir()</TT
+> filesystem function pointer has two
+modes of use. When passed a pointer in the
+<TT
+CLASS="PARAMETER"
+><I
+>dir_out</I
+></TT
+> argument, it should locate the named
+directory and place a directory pointer there. If the
+<TT
+CLASS="PARAMETER"
+><I
+>dir_out</I
+></TT
+> argument is NULL then the
+<TT
+CLASS="PARAMETER"
+><I
+>dir</I
+></TT
+> argument is a previously generated
+directory pointer that can now be disposed of. When the infrastructure
+is implementing the <TT
+CLASS="FUNCTION"
+>chdir()</TT
+> function it makes two
+calls to filesystem <TT
+CLASS="FUNCTION"
+>chdir()</TT
+> functions. The first
+is to get a directory pointer for the new current directory. If this
+succeeds the second is to dispose of the old current directory
+pointer.</P
+><P
+>The <TT
+CLASS="FUNCTION"
+>opendir()</TT
+> function is used to open a
+directory for reading. This results in an open file object that can be
+read to return a sequence of <SPAN
+CLASS="STRUCTNAME"
+>struct dirent</SPAN
+>
+objects. The only operations that are allowed on this file are
+<TT
+CLASS="FUNCTION"
+>read</TT
+>, <TT
+CLASS="FUNCTION"
+>lseek</TT
+> and
+<TT
+CLASS="FUNCTION"
+>close</TT
+>. Each read operation on this file should
+return a single <SPAN
+CLASS="STRUCTNAME"
+>struct dirent</SPAN
+> object. When
+the end of the directory is reached, zero should be returned. The only
+seek operation allowed is a rewind to the start of the directory, by
+supplying an offset of zero and a <TT
+CLASS="PARAMETER"
+><I
+>whence</I
+></TT
+>
+specifier of <TT
+CLASS="LITERAL"
+>SEEK_SET</TT
+>.</P
+><P
+>Most of these considerations are invisible to clients of a filesystem
+since they will access directories via the POSIX
+<TT
+CLASS="FUNCTION"
+>opendir()</TT
+>, <TT
+CLASS="FUNCTION"
+>readdir()</TT
+> and
+<TT
+CLASS="FUNCTION"
+>closedir()</TT
+> functions.</P
+><P
+>Support for the <TT
+CLASS="FUNCTION"
+>getcwd()</TT
+> function is provided by
+three mechanisms. The first is to use the
+<TT
+CLASS="LITERAL"
+>FS_INFO_GETCWD</TT
+> getinfo key on the filesystem to use
+any internal support that it has for this. If that fails it falls back
+on one of the two other mechanisms. If
+<TT
+CLASS="LITERAL"
+>CYGPKG_IO_FILEIO_TRACK_CWD</TT
+> is set then the current
+directory is tracked textually in <TT
+CLASS="FUNCTION"
+>chdir()</TT
+> and the result of that is
+reported in getcwd(). Otherwise an attempt is made to traverse the
+directory tree to its root using ".." entries.</P
+><P
+>This last option is complicated and expensive, and relies on the
+filesystem supporting "." and ".." entries. This is not always the
+case, particularly if the filesystem has been ported from a
+non-UNIX-compatible source. Tracking the pathname textually will
+usually work, but might not produce optimum results when symbolic
+links are being used.</P
+></DIV
+><DIV
+CLASS="NAVFOOTER"
+><HR
+ALIGN="LEFT"
+WIDTH="100%"><TABLE
+SUMMARY="Footer navigation table"
+WIDTH="100%"
+BORDER="0"
+CELLPADDING="0"
+CELLSPACING="0"
+><TR
+><TD
+WIDTH="33%"
+ALIGN="left"
+VALIGN="top"
+><A
+HREF="fileio-file-table.html"
+ACCESSKEY="P"
+>Prev</A
+></TD
+><TD
+WIDTH="34%"
+ALIGN="center"
+VALIGN="top"
+><A
+HREF="ecos-ref.html"
+ACCESSKEY="H"
+>Home</A
+></TD
+><TD
+WIDTH="33%"
+ALIGN="right"
+VALIGN="top"
+><A
+HREF="fileio-synchronization.html"
+ACCESSKEY="N"
+>Next</A
+></TD
+></TR
+><TR
+><TD
+WIDTH="33%"
+ALIGN="left"
+VALIGN="top"
+>File Table</TD
+><TD
+WIDTH="34%"
+ALIGN="center"
+VALIGN="top"
+><A
+HREF="fileio.html"
+ACCESSKEY="U"
+>Up</A
+></TD
+><TD
+WIDTH="33%"
+ALIGN="right"
+VALIGN="top"
+>Synchronization</TD
+></TR
+></TABLE
+></DIV
+></BODY
+></HTML
+>
\ No newline at end of file
projects / karo-tx-redboot.git / blobdiff