freebsd-skq/share/man/man5/dir.5
kib e75ba1d5c4 Commit the 64-bit inode project.
Extend the ino_t, dev_t, nlink_t types to 64-bit ints.  Modify
struct dirent layout to add d_off, increase the size of d_fileno
to 64-bits, increase the size of d_namlen to 16-bits, and change
the required alignment.  Increase struct statfs f_mntfromname[] and
f_mntonname[] array length MNAMELEN to 1024.

ABI breakage is mitigated by providing compatibility using versioned
symbols, ingenious use of the existing padding in structures, and
by employing other tricks.  Unfortunately, not everything can be
fixed, especially outside the base system.  For instance, third-party
APIs which pass struct stat around are broken in backward and
forward incompatible ways.

Kinfo sysctl MIBs ABI is changed in backward-compatible way, but
there is no general mechanism to handle other sysctl MIBS which
return structures where the layout has changed. It was considered
that the breakage is either in the management interfaces, where we
usually allow ABI slip, or is not important.

Struct xvnode changed layout, no compat shims are provided.

For struct xtty, dev_t tty device member was reduced to uint32_t.
It was decided that keeping ABI compat in this case is more useful
than reporting 64-bit dev_t, for the sake of pstat.

Update note: strictly follow the instructions in UPDATING.  Build
and install the new kernel with COMPAT_FREEBSD11 option enabled,
then reboot, and only then install new world.

Credits: The 64-bit inode project, also known as ino64, started life
many years ago as a project by Gleb Kurtsou (gleb).  Kirk McKusick
(mckusick) then picked up and updated the patch, and acted as a
flag-waver.  Feedback, suggestions, and discussions were carried
by Ed Maste (emaste), John Baldwin (jhb), Jilles Tjoelker (jilles),
and Rick Macklem (rmacklem).  Kris Moore (kris) performed an initial
ports investigation followed by an exp-run by Antoine Brodin (antoine).
Essential and all-embracing testing was done by Peter Holm (pho).
The heavy lifting of coordinating all these efforts and bringing the
project to completion were done by Konstantin Belousov (kib).

Sponsored by:	The FreeBSD Foundation (emaste, kib)
Differential revision:	https://reviews.freebsd.org/D10439
2017-05-23 09:29:05 +00:00

168 lines
5.7 KiB
Groff

.\" Copyright (c) 1983, 1991, 1993
.\" The Regents of the University of California. All rights reserved.
.\"
.\" 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 REGENTS 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 REGENTS 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.
.\"
.\" @(#)dir.5 8.3 (Berkeley) 4/19/94
.\" $FreeBSD$
.\"
.Dd February 13, 2017
.Dt DIR 5
.Os
.Sh NAME
.Nm dir ,
.Nm dirent
.Nd directory file format
.Sh SYNOPSIS
.In dirent.h
.Sh DESCRIPTION
Directories provide a convenient hierarchical method of grouping
files while obscuring the underlying details of the storage medium.
A directory file is differentiated from a plain file
by a flag in its
.Xr inode 5
entry.
It consists of records (directory entries) each of which contains
information about a file and a pointer to the file itself.
Directory entries may contain other directories
as well as plain files; such nested directories are referred to as
subdirectories.
A hierarchy of directories and files is formed in this manner
and is called a file system (or referred to as a file system tree).
.\" An entry in this tree,
.\" nested or not nested,
.\" is a pathname.
.Pp
Each directory file contains two special directory entries; one is a pointer
to the directory itself
called dot
.Ql .\&
and the other a pointer to its parent directory called dot-dot
.Ql \&.. .
Dot and dot-dot
are valid pathnames, however,
the system root directory
.Ql / ,
has no parent and dot-dot points to itself like dot.
.Pp
File system nodes are ordinary directory files on which has
been grafted a file system object, such as a physical disk or a
partitioned area of such a disk.
(See
.Xr mount 2
and
.Xr mount 8 . )
.Pp
The directory entry format is defined in the file
.In sys/dirent.h
(which should not be included directly by applications):
.Bd -literal
#ifndef _SYS_DIRENT_H_
#define _SYS_DIRENT_H_
#include <machine/ansi.h>
/*
* The dirent structure defines the format of directory entries returned by
* the getdirentries(2) system call.
*
* A directory entry has a struct dirent at the front of it, containing its
* inode number, the length of the entry, and the length of the name
* contained in the entry. These are followed by the name padded to a 4
* byte boundary with null bytes. All names are guaranteed null terminated.
* The maximum length of a name in a directory is MAXNAMLEN.
* Explicit pad is added between the last member of the header and
* d_name, to avoid having the ABI padding in the end of dirent on
* LP64 arches. There is code depending on d_name being last. Also,
* keeping this pad for ILP32 architectures simplifies compat32 layer.
*/
struct dirent {
ino_t d_fileno; /* file number of entry */
off_t d_off; /* directory offset of entry */
__uint16_t d_reclen; /* length of this record */
__uint8_t d_type; /* file type, see below */
__uint8_t d_namlen; /* length of string in d_name */
__uint32_t d_pad0;
#if __BSD_VISIBLE
#define MAXNAMLEN 255
char d_name[MAXNAMLEN + 1]; /* name must be no longer than this */
#else
char d_name[255 + 1]; /* name must be no longer than this */
#endif
};
/*
* File types
*/
#define DT_UNKNOWN 0
#define DT_FIFO 1
#define DT_CHR 2
#define DT_DIR 4
#define DT_BLK 6
#define DT_REG 8
#define DT_LNK 10
#define DT_SOCK 12
#define DT_WHT 14
/*
* Convert between stat structure types and directory types.
*/
#define IFTODT(mode) (((mode) & 0170000) >> 12)
#define DTTOIF(dirtype) ((dirtype) << 12)
/*
* The _GENERIC_DIRSIZ macro gives the minimum record length which will hold
* the directory entry. This returns the amount of space in struct direct
* without the d_name field, plus enough space for the name with a terminating
* null byte (dp->d_namlen+1), rounded up to a 8 byte boundary.
*
* XXX although this macro is in the implementation namespace, it requires
* a manifest constant that is not.
*/
#define _GENERIC_DIRLEN(namlen) \
((__offsetof(struct dirent, d_name) + (namlen) + 1 + 7) & ~7)
#define _GENERIC_DIRSIZ(dp) _GENERIC_DIRLEN((dp)->d_namlen)
#endif /* __BSD_VISIBLE */
#ifdef _KERNEL
#define GENERIC_DIRSIZ(dp) _GENERIC_DIRSIZ(dp)
#endif
#endif /* !_SYS_DIRENT_H_ */
.Ed
.Sh SEE ALSO
.Xr fs 5 ,
.Xr inode 5
.Sh HISTORY
A
.Nm
file format appeared in
.At v7 .
.Sh BUGS
The usage of the member d_type of struct dirent is unportable as it is
.Fx Ns -specific .
It also may fail on certain file systems, for example the cd9660 file system.