xref: /freebsd/share/man/man5/dir.5 (revision 282a3889ebf826db9839be296ff1dd903f6d6d6e)
1.\" Copyright (c) 1983, 1991, 1993
2.\"	The Regents of the University of California.  All rights reserved.
3.\"
4.\" Redistribution and use in source and binary forms, with or without
5.\" modification, are permitted provided that the following conditions
6.\" are met:
7.\" 1. Redistributions of source code must retain the above copyright
8.\"    notice, this list of conditions and the following disclaimer.
9.\" 2. Redistributions in binary form must reproduce the above copyright
10.\"    notice, this list of conditions and the following disclaimer in the
11.\"    documentation and/or other materials provided with the distribution.
12.\" 3. All advertising materials mentioning features or use of this software
13.\"    must display the following acknowledgement:
14.\"	This product includes software developed by the University of
15.\"	California, Berkeley and its contributors.
16.\" 4. Neither the name of the University nor the names of its contributors
17.\"    may be used to endorse or promote products derived from this software
18.\"    without specific prior written permission.
19.\"
20.\" THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND
21.\" ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
22.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
23.\" ARE DISCLAIMED.  IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE
24.\" FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
25.\" DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
26.\" OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
27.\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
28.\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
29.\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
30.\" SUCH DAMAGE.
31.\"
32.\"     @(#)dir.5	8.3 (Berkeley) 4/19/94
33.\" $FreeBSD$
34.\"
35.Dd April 19, 1994
36.Dt DIR 5
37.Os
38.Sh NAME
39.Nm dir ,
40.Nm dirent
41.Nd directory file format
42.Sh SYNOPSIS
43.In dirent.h
44.Sh DESCRIPTION
45Directories provide a convenient hierarchical method of grouping
46files while obscuring the underlying details of the storage medium.
47A directory file is differentiated from a plain file
48by a flag in its
49.Xr inode 5
50entry.
51It consists of records (directory entries) each of which contains
52information about a file and a pointer to the file itself.
53Directory entries may contain other directories
54as well as plain files; such nested directories are referred to as
55subdirectories.
56A hierarchy of directories and files is formed in this manner
57and is called a file system (or referred to as a file system tree).
58.\" An entry in this tree,
59.\" nested or not nested,
60.\" is a pathname.
61.Pp
62Each directory file contains two special directory entries; one is a pointer
63to the directory itself
64called dot
65.Ql .\&
66and the other a pointer to its parent directory called dot-dot
67.Ql \&.. .
68Dot and dot-dot
69are valid pathnames, however,
70the system root directory
71.Ql / ,
72has no parent and dot-dot points to itself like dot.
73.Pp
74File system nodes are ordinary directory files on which has
75been grafted a file system object, such as a physical disk or a
76partitioned area of such a disk.
77(See
78.Xr mount 2
79and
80.Xr mount 8 . )
81.Pp
82The directory entry format is defined in the file
83.In sys/dirent.h
84(which should not be included directly by applications):
85.Bd -literal
86#ifndef	_SYS_DIRENT_H_
87#define	_SYS_DIRENT_H_
88
89#include <machine/ansi.h>
90
91/*
92 * The dirent structure defines the format of directory entries returned by
93 * the getdirentries(2) system call.
94 *
95 * A directory entry has a struct dirent at the front of it, containing its
96 * inode number, the length of the entry, and the length of the name
97 * contained in the entry.  These are followed by the name padded to a 4
98 * byte boundary with null bytes.  All names are guaranteed null terminated.
99 * The maximum length of a name in a directory is MAXNAMLEN.
100 */
101
102struct dirent {
103	__uint32_t d_fileno;		/* file number of entry */
104	__uint16_t d_reclen;		/* length of this record */
105	__uint8_t  d_type; 		/* file type, see below */
106	__uint8_t  d_namlen;		/* length of string in d_name */
107#ifdef _POSIX_SOURCE
108	char	d_name[255 + 1];	/* name must be no longer than this */
109#else
110#define	MAXNAMLEN	255
111	char	d_name[MAXNAMLEN + 1];	/* name must be no longer than this */
112#endif
113};
114
115/*
116 * File types
117 */
118#define	DT_UNKNOWN	 0
119#define	DT_FIFO		 1
120#define	DT_CHR		 2
121#define	DT_DIR		 4
122#define	DT_BLK		 6
123#define	DT_REG		 8
124#define	DT_LNK		10
125#define	DT_SOCK		12
126#define	DT_WHT		14
127
128/*
129 * Convert between stat structure types and directory types.
130 */
131#define	IFTODT(mode)	(((mode) & 0170000) >> 12)
132#define	DTTOIF(dirtype)	((dirtype) << 12)
133
134/*
135 * The _GENERIC_DIRSIZ macro gives the minimum record length which will hold
136 * the directory entry.  This requires the amount of space in struct direct
137 * without the d_name field, plus enough space for the name with a terminating
138 * null byte (dp->d_namlen+1), rounded up to a 4 byte boundary.
139 */
140#define	_GENERIC_DIRSIZ(dp) \
141    ((sizeof (struct dirent) - (MAXNAMLEN+1)) + (((dp)->d_namlen+1 + 3) &~ 3))
142
143#ifdef _KERNEL
144#define	GENERIC_DIRSIZ(dp)	_GENERIC_DIRSIZ(dp)
145#endif
146
147#endif /* !_SYS_DIRENT_H_ */
148.Ed
149.Sh SEE ALSO
150.Xr fs 5 ,
151.Xr inode 5
152.Sh HISTORY
153A
154.Nm
155file format appeared in
156.At v7 .
157.Sh BUGS
158The usage of the member d_type of struct dirent is unportable as it is
159.Fx Ns -specific .
160It also may fail on certain file systems, for example the cd9660 file system.
161