|
|
1.1 root 1:
2:
3: NOTES FOR NEARLY-POSIX-COMPATIBLE C LIBRARY DIRECTORY-ACCESS ROUTINES
4:
5:
6: Older UNIX C libraries lacked support for reading directories, so historically
7: programs had knowledge of UNIX directory structure hard-coded into them. When
8: Berkeley changed the format of directories for 4.2BSD, it became necessary to
9: change programs to work with the new structure. Fortunately, Berkeley designed
10: a small set of directory access routines to encapsulate knowledge of the new
11: directory format so that user programs could deal with directory entries as an
12: abstract data type. (Unfortunately, they didn't get it quite right.) The
13: interface to these routines was nearly independent of the particular
14: implementation of directories on any given UNIX system; this has become a
15: particularly important requirement with the advent of heterogeneous network
16: filesystems such as NFS.
17:
18: It has consequently become possible to write portable applications that search
19: directories by restricting all directory access to use these new interface
20: routines. The sources supplied here are a total rewrite of Berkeley's code,
21: incorporating ideas from a variety of sources and conforming as closely to
22: published standards as possible, and are in the PUBLIC DOMAIN to encourage
23: their widespread adoption. They support four methods of access to system
24: directories: the original UNIX filesystem via read(), the 4.2BSD filesystem via
25: read(), NFS and native filesystems via getdirentries(), and SVR3 getdents().
26: The other three types are accomplished by appropriate emulation of the SVR3
27: getdents() system call, which attains portability at the cost of slightly more
28: data movement than absolutely necessary for some systems. These routines
29: should be added to the standard C library on all UNIX systems, and all existing
30: and future applications should be changed to use this interface. Once this is
31: done, there should be no portability problems due to differences in underlying
32: directory structures among UNIX systems. (When porting your applications to
33: other UNIX systems, you can always carry this package around with you.)
34:
35: An additional benefit of these routines is that they buffer directory input,
36: which provides improved access speed over raw read()s of one entry at a time.
37:
38: One annoying compatibility problem has arisen along the way, namely that the
39: original Berkeley interface used the same name, struct direct, for the new data
40: structure as had been used for the original UNIX filesystem directory record
41: structure. This name was changed by the IEEE 1003.1 (POSIX) Working Group to
42: "struct dirent" and was picked up for SVR3 under the new name; it is also the
43: name used in this portable package. I believe it is necessary to bite the
44: bullet and adopt the new non-conflicting name. Code using a 4.2BSD-compatible
45: package needs to be slightly revised to work with this new package, as follows:
46: Change
47: #include <ndir.h> /* Ninth Edition UNIX */
48: or
49: #include <sys/dir.h> /* 4.2BSD */
50: or
51: #include <dir.h> /* BRL System V emulation */
52: to
53: #include <sys/types.h> /* if not already #included */
54: #include <dirent.h>
55:
56: Change
57: struct direct
58: to
59: struct dirent
60:
61: Change
62: (anything)->d_namlen
63: to
64: strlen( (anything)->d_name )
65:
66: There is a minor compatibility problem in that the closedir() function was
67: originally defined to have type void, but IEEE 1003.1 changed this to type int,
68: which is what this implementation supports (even though I disagree with the
69: change). However, the difference does not affect most applications.
70:
71: Another minor problem is that IEEE 1003.1 defined the d_name member of a struct
72: dirent to be an array of maximum length; this does not permit use of compact
73: variable-length entries directly from a directory block buffer. This part of
74: the specification is incompatible with efficient use of the getdents() system
75: call, and I have therefore chosen to follow the SVID specification instead of
76: IEEE 1003.1 (which I hope is changed for the final-use standard). This
77: deviation should have little or no impact on sensibly-coded applications, since
78: the relevant d_name length is that given by strlen(), not the declared array
79: size.
80:
81: Error handling is not completely satisfactory, due to the variety of possible
82: failure modes in a general setting. For example, the rewinddir() function
83: might fail, but there is no good way to indicate this. I have tried to
84: follow the specifications in IEEE 1003.1 and the SVID as closely as possible,
85: but there are minor deviations in this regard. Applications should not rely
86: too heavily on exact failure mode semantics.
87:
88: Please do not change the new standard interface in any way, as that would
89: defeat the major purpose of this package! (It's okay to alter the internal
90: implementation if you really have to, although I tried to make this unnecessary
91: for the vast majority of UNIX variants.)
92:
93: Installation instructions can be found in the file named INSTALL.
94:
95: This implementation is provided by:
96:
97: Douglas A. Gwyn
98: U.S. Army Ballistic Research Laboratory
99: SLCBR-VL-V
100: Aberdeen Proving Ground, MD 21005-5066
101:
102: (301)278-6647
103:
104: [email protected] or seismo!brl!gwyn
105:
106: This is UNSUPPORTED, use-at-your-own-risk, free software in the public domain.
107: However, I would appreciate hearing of any actual bugs you find in this
108: implementation and/or any improvements you come up with.
This archive runs on limited infrastructure. Preserving old code on modern bandwidth. Automated agents are requested to crawl responsibly.