Content deleted Content added
No edit summary Tags: Mobile edit Mobile app edit iOS app edit |
Thunder491 (talk | contribs) m Move {{Redirect}} to relevant section |
||
| (26 intermediate revisions by 21 users not shown) | |||
Line 1:
{{Short description|Directory structure used by a Unix-like operating system}}
{{Redirect|Usr||USR (disambiguation){{!}}USR}}▼
{{Redirect|Unix file system|UFS, a specific file system used by many Unix and Unix-like operating systems|Unix File System}}
[[File:Version 7 UNIX SIMH PDP11 Filesystem Layout.png|thumb|[[Version 7 Unix]] filesystem layout: subdirectories of "/" and "/usr"]]
[[File:Standard-unix-filesystem-hierarchy.svg|thumb|An overview of a [[Unix]] filesystem layout]]
In [[Unix]] and [[operating system]]s inspired by it, the [[file system]] is considered a central component of the operating system.<ref name="
As in other operating systems, the filesystem provides information storage and retrieval, and one of several forms of [[interprocess communication]], in that the many small programs that traditionally form a Unix system can store information in files so that other programs can read them, although [[Pipeline (Unix)|pipes]] complemented it in this role starting with the [[Research Unix|Third Edition]]. Also, the filesystem provides access to other resources through so-called ''[[device file]]s'' that are entry points to [[computer terminal|terminals]], [[computer printer|printers]], and [[computer mouse|mice]].
Line 15:
In the original [[Research Unix|Bell Labs Unix]], a two-disk setup was customary, where the first disk contained startup programs, while the second contained users' files and programs. This second disk was mounted at the empty directory named <code>usr</code> on the first disk, causing the two disks to appear as one filesystem, with the second disk’s contents viewable at <code>/usr</code>.
Unix directories do not ''contain'' files. Instead, they contain the names of files paired with references to so-called [[inode]]s, which in turn contain both the file and its [[metadata]] (owner, permissions, time of last access, etc., but no name). Multiple names in the file system may refer to the same file, a feature termed a ''[[hard link]]''.<ref name="Ritchie"/> The mathematical traits of hard links make the file system a limited type of [[directed acyclic graph]], although the ''directories'' still form a tree, as they typically may not be hard-linked.<!--Mac OS X allows this, according to the article 'Hard link'.--> (As originally envisioned in 1969, the Unix file system would in fact be used as a general graph with hard links to directories providing navigation, instead of path names.<ref name="evolution">{{cite conference |first=Dennis M. |last=Ritchie |year=1979 |title=The Evolution of the Unix Time-sharing System |conference=Language Design and Programming Methodology Conf. |url=http://cm.bell-labs.com/cm/cs/who/dmr/hist.html |access-date=2014-04-20 |archive-date=2015-04-08 |archive-url=https://web.archive.org/web/20150408054606/http://cm.bell-labs.com/cm/cs/who/dmr/hist.html |url-status=dead }}</ref>)
===File types===
{{Main |Unix file types}}
The original Unix file system supported three types of files: ordinary files, [[Directory (computing)|directories]], and "special files", also termed device files.<ref name="Ritchie"/> The [[Berkeley Software Distribution]] (BSD) and [[UNIX System V|System V]] each added a file type to be used for [[interprocess communication]]: BSD added [[Berkeley sockets|sockets]],<ref name="43bsd">{{cite book |last1= Leffler |first1= Samuel J. |
BSD also added [[symbolic link]]s (often termed "symlinks") to the range of file types, which are files that refer to other files, and complement hard links.<ref name="43bsd"/> Symlinks were modeled after a similar feature in [[Multics]],<ref name="FFS">{{cite web|last1=McKusick|display-authors=etal|first1=Marshall Kirk|title=A Fast Filesystem for Unix|url=https://docs.freebsd.org/44doc/smm/05.fastfs/paper.pdf|website=Freebsd.org|publisher=CSRG, UC Berkeley|
==Conventional directory layout==
Certain conventions exist for locating some kinds of files, such as programs, system configuration files, and users' [[home directory|home directories]]. These were first documented in the <code>hier(7)</code> [[man page]] since [[Version 7 Unix]];<ref name="v7">{{man|7|hier|v7}}</ref> subsequent versions, derivatives and clones typically have a similar man page.<ref>{{man|7|hier|FreeBSD}}</ref><ref name="openbsd">{{man|7|hier|OpenBSD}}</ref><ref>{{cite web|title=hier(7) man page for 2.9.1 BSD|url=http://www.freebsd.org/cgi/man.cgi?query=hier&manpath=2.9.1+BSD}}</ref><ref>{{cite web|title=hier(7) man page for ULTRIX 4.2|url=http://www.freebsd.org/cgi/man.cgi?query=hier&manpath=ULTRIX+4.2}}</ref><ref>{{cite web|title=hier(7) man page for SunOS 4.1.3|url=http://www.freebsd.org/cgi/man.cgi?query=hier&manpath=SunOS+4.1.3}}</ref><ref>{{man|7|hier|Linux}}</ref>
The details of the directory layout have varied over time. Although the file system layout is not part of the [[Single UNIX Specification]], several attempts exist to standardize (parts of) it, such as the [[UNIX System V|System V]] [[Application Binary Interface]], the [[Intel Binary Compatibility Standard]], the Common Operating System Environment, and [[Linux Foundation]]'s [[Filesystem Hierarchy Standard]] (FHS).<ref>{{cite web |title=Where to Install My Products on Linux? |url=http://www.linuxjournal.com/article/4121 |website=[[Linux Journal]] |date=1 November 2000 |author=George Kraft IV |
Here is a generalized overview of common locations of files on a Unix operating system:
Line 38 ⟶ 39:
|-
|
|Stands for ''[[computer program|binaries]]'' and contains certain fundamental utilities, such as <code>ls</code> or <code>cp</code>, that are needed to mount <code>/usr</code>, when that is a separate filesystem, or to run in one-user (administrative) mode when <code>/usr</code> cannot be mounted. In System V.4, this is a symlink to <code>/usr/bin</code>. Otherwise, it needs to be on the root filesystem itself.
|-
|
|Contains all the files needed for successful booting process. In [[Research Unix]], this was one file rather than a directory.<ref name="upe"/> Nowadays usually on the root filesystem itself, unless the system, bootloader etc. require otherwise.
|-
|
|Stands for ''devices''. Contains [[device node|file representations]] of peripheral devices and [[Device file#Pseudo-devices|pseudo-devices]]. See also: [[Linux Assigned Names and Numbers Authority]]. Needs to be on the root filesystem itself.
|-
|
|Contains system-wide configuration files and system databases; the name stands for ''[[et cetera]]''
|-
|
|Contains user home directories on Linux and some other systems. In the original version of Unix, home directories were in <code>/usr</code> instead.<ref name="notes72">{{cite web|last=Ritchie|first=Dennis|title=Unix Notes from 1972|url=https://www.bell-labs.com/usr/dmr/www/notes.html|
|-
|
|Originally ''essential libraries'': [[C (programming language)|C]] libraries, but not [[Fortran]] ones.<ref name="upe"/> On modern systems, it contains the shared libraries needed by programs in <code>/bin</code>, and possibly [[loadable kernel module]]
|-
|
|Default mount point for removable devices, such as USB sticks, media players, etc. By common sense, the directory itself, whose subdirectories are mountpoints, is on the root partition itself.
|-
|
|Stands for ''mount''. Empty directory commonly used by system administrators as a temporary mount point. By common sense, the directory itself, whose subdirectories are mountpoints, is on the root partition itself.
|-
|
|Contains locally installed software. Originated in [[UNIX System V|System V]], which has a [[package manager]] that installs software to this directory (one subdirectory per package).<ref>''[http://www.sco.com/developers/devspecs/gabi41.pdf System V Application Binary Interface]'' Edition 4.1 (1997-03-18)</ref>
|-
|
|[[procfs]] virtual [[File system|filesystem]] showing information about [[process (computing)|processes]] as files.
|-
|
|The home directory for the [[superuser]] ''root'' - that is, the system administrator. This account's home directory is usually on the initial filesystem, and hence not in /home (which may be a mount point for another filesystem) in case specific maintenance needs to be performed, during which other filesystems are not available. Such a case could occur, for example, if a hard disk drive suffers
|-
|
|Stands for "[[computer program|system (or superuser) binaries]]" and contains fundamental utilities, such as <code>init</code>, usually needed to start, maintain and recover the system. Needs to be on the root partition itself.
|-
|
|Server data (data for services provided by system).
|-
|
|In some [[Linux distribution]]s, contains a [[sysfs]] virtual [[File system|filesystem]], containing information related to hardware and the operating system. On BSD systems, commonly a symlink to the kernel sources in <code>/usr/src/sys</code>.
|-
|
|A place for temporary files not expected to survive a reboot. Many systems clear this directory upon startup or use [[tmpfs]] to implement it.
|-
|
|The Unix [[kernel (
|-
|
|The "user file system": originally the directory holding user home directories,<ref name="notes72"/> but already by the Third Edition of [[Research Unix]], ca. 1973, reused to split the operating system's programs over two disks (one of them a 256K fixed-head drive) so that basic commands would either appear in <code>/bin</code> or <code>/usr/bin</code>.<ref name="reader">
|-
|
|Stores the development headers used throughout the system. [[Header file]]s are mostly used by the <code>#include</code> directive in [[C (programming language)|C]] language, which historically is how the name of this directory was chosen.
|-
|
|Stores the needed libraries and data files for programs stored within <code>/usr</code> or elsewhere.
|-
|
|Holds programs meant to be executed by other programs rather than by users directly. E.g., the [[Sendmail]] executable may be found in this directory.<ref>{{cite web |url=http://docs.cray.com/books/S-2341-22/html-S-2341-22/z1028736068smg.html |website=[[UNICOS]]/mp Networking Facilities Administration |publisher=[[Cray]] |title=Chapter 7. sendmail |
|-
|
|Resembles <code>/usr</code> in structure, but its subdirectories are used for additions not part of the operating system distribution, such as custom programs or files from a [[BSD]] [[Ports collection]]. Usually has subdirectories such as <code>/usr/local/lib</code> or <code>/usr/local/bin</code>.
|-
|
|Architecture-independent program data. On Linux and modern BSD derivatives, this directory has subdirectories such as <code>man</code> for [[manpage]]s, that used to appear directly under <code>/usr</code> in older versions.
|-
|
|Stands for ''variable''. A place for files that might change frequently - especially in size, for example e-mail sent to users on the system, or process-ID [[lock file]]s.
|-
|
|Contains system log files.
|-
|
|The place where all incoming mail is stored. Users (other than <code>root</code>) can access their own mail only. Often, this directory is a [[symbolic link]] to <code>/var/spool/mail</code>.
|-
|
|[[spooling|Spool]] directory. Contains print jobs, mail spools and other queued tasks.
|-
|
|The place where the uncompiled source code of some programs is.
|-
|
|The <code>/var/tmp</code> directory is a place for temporary files which should be preserved between system reboots.
|}
Line 165 ⟶ 166:
*{{Citizendium}}
{{Reflist|30em}}
{{Unix}}
{{DEFAULTSORT:Unix Directory Structure}}
| |||