1 <!-- Copyright (C) 2003 Red Hat, Inc. -->
2 <!-- This material may be distributed only subject to the terms -->
3 <!-- and conditions set forth in the Open Publication License, v1.0 -->
4 <!-- or later (the latest version is presently available at -->
5 <!-- http://www.opencontent.org/openpub/). -->
6 <!-- Distribution of the work or derivative of the work in any -->
7 <!-- standard (paper) book form is prohibited unless prior -->
8 <!-- permission is obtained from the copyright holder. -->
13 ><meta name="MSSmartTagsPreventParsing" content="TRUE">
16 CONTENT="Modular DocBook HTML Stylesheet Version 1.76b+
19 TITLE="eCos Reference Manual"
20 HREF="ecos-ref.html"><LINK
22 TITLE="File System Support Infrastructure"
23 HREF="fileio.html"><LINK
26 HREF="fileio-file-table.html"><LINK
28 TITLE="Synchronization"
29 HREF="fileio-synchronization.html"></HEAD
40 SUMMARY="Header navigation table"
49 >eCos Reference Manual</TH
57 HREF="fileio-file-table.html"
71 HREF="fileio-synchronization.html"
84 NAME="FILEIO-DIRECTORIES">Chapter 23. Directories</H1
86 >Filesystem operations all take a directory pointer as one of their
87 arguments. A directory pointer is an opaque handle managed by the
88 filesystem. It should encapsulate a reference to a specific directory
89 within the filesystem. For example, it may be a pointer to the data
90 structure that represents that directory (such as an inode), or a
91 pointer to a pathname for the directory.</P
96 > filesystem function pointer has two
97 modes of use. When passed a pointer in the
103 > argument, it should locate the named
104 directory and place a directory pointer there. If the
110 > argument is NULL then the
116 > argument is a previously generated
117 directory pointer that can now be disposed of. When the infrastructure
118 is implementing the <TT
121 > function it makes two
122 calls to filesystem <TT
125 > functions. The first
126 is to get a directory pointer for the new current directory. If this
127 succeeds the second is to dispose of the old current directory
133 > function is used to open a
134 directory for reading. This results in an open file object that can be
135 read to return a sequence of <SPAN
139 objects. The only operations that are allowed on this file are
150 >. Each read operation on this file should
151 return a single <SPAN
155 the end of the directory is reached, zero should be returned. The only
156 seek operation allowed is a rewind to the start of the directory, by
157 supplying an offset of zero and a <TT
168 >Most of these considerations are invisible to clients of a filesystem
169 since they will access directories via the POSIX
185 > function is provided by
186 three mechanisms. The first is to use the
190 > getinfo key on the filesystem to use
191 any internal support that it has for this. If that fails it falls back
192 on one of the two other mechanisms. If
195 >CYGPKG_IO_FILEIO_TRACK_CWD</TT
196 > is set then the current
197 directory is tracked textually in <TT
200 > and the result of that is
201 reported in getcwd(). Otherwise an attempt is made to traverse the
202 directory tree to its root using ".." entries.</P
204 >This last option is complicated and expensive, and relies on the
205 filesystem supporting "." and ".." entries. This is not always the
206 case, particularly if the filesystem has been ported from a
207 non-UNIX-compatible source. Tracking the pathname textually will
208 usually work, but might not produce optimum results when symbolic
209 links are being used.</P
216 SUMMARY="Footer navigation table"
227 HREF="fileio-file-table.html"
245 HREF="fileio-synchronization.html"