56-1234: In Unix-like operating systems , a device file , device node , or special file is an interface to a device driver that appears in a file system as if it were an ordinary file . There are also special files in DOS , OS/2 , and Windows . These special files allow an application program to interact with a device by using its device driver via standard input/output system calls . Using standard system calls simplifies many programming tasks, and leads to consistent user-space I/O mechanisms regardless of device features and functions. Device files usually provide simple interfaces to standard devices (such as printers and serial ports), but can also be used to access specific unique resources on those devices, such as disk partitions . Additionally, device files are useful for accessing system resources that have no connection with any actual device, such as data sinks and random number generators . There are two general kinds of device files in Unix-like operating systems, known as character special files and block special files . The difference between them lies in how much data
112-424: A node . The assignment of these numbers occurs uniquely in different operating systems and on different computer platforms . Generally, the major number identifies the device driver and the minor number identifies a particular device (possibly out of many) that the driver controls: in this case, the system may pass the minor number to a driver. However, in the presence of dynamic number allocation , this may not be
168-401: A virtual file system traditionally mounted at /dev , possibly associated with a controlling daemon, which monitors hardware addition and removal at run time, making corresponding changes to the device file system if that's not automatically done by the kernel, and possibly invoking scripts in system or user space to handle special device needs. The FreeBSD , DragonFly BSD and Darwin have
224-473: A POSIX compatibility layer and are not otherwise inherently Unix systems. Many ancient UNIX systems no longer meet this definition. Broadly, any Unix-like system that behaves in a manner roughly consistent with the UNIX specification, including having a " program which manages your login and command line sessions "; more specifically, this can refer to systems such as Linux or Minix that behave similarly to
280-470: A UNIX system but have no genetic or trademark connection to the AT&;T code base. Most free/open-source implementations of the UNIX design, whether genetic UNIX or not, fall into the restricted definition of this third category due to the expense of obtaining Open Group certification, which costs thousands of dollars. Around 2001 Linux was given the opportunity to get a certification including free help from
336-520: A dedicated file system devfs ; device nodes are managed automatically by this file system, in kernel space . Linux used to have a similar devfs implementation, but it was abandoned later, and then removed since version 2.6.17; Linux now primarily uses a user space implementation known as udev , but there are many variants. In Unix systems which support chroot process isolation, such as Solaris Containers , typically each chroot environment needs its own /dev ; these mount points will be visible on
392-450: A device already in use would discover itself unable to open the device file node. A variety of device driver semantics are implemented in Unix and Linux concerning concurrent access . Device nodes correspond to resources that an operating system's kernel has already allocated. Unix identifies those resources by a major number and a minor number , both stored as part of the structure of
448-504: A file or directory overall, not by a class, though in the symbolic notation (see below) the setuid bit is set in the triad for the user, the setgid bit is set in the triad for the group and the sticky bit is set in the triad for others. These additional modes are also referred to as setuid bit , setgid bit , and sticky bit , due to the fact that they each occupy only one bit. Unix permissions are represented either in symbolic notation or in octal notation. The most common form, as used by
504-399: A fourth digit is present, the leftmost (high-order) digit addresses three additional attributes, the setuid bit , the setgid bit and the sticky bit .) Each of these digits is the sum of its component bits in the binary numeral system . As a result, specific bits add to the sum as it is represented by a numeral: These values never produce ambiguous combinations; each sum represents
560-596: A historical connection to the AT&;T codebase. Most commercial UNIX systems fall into this category. So do the BSD systems, which are descendants of work done at the University of California, Berkeley in the late 1970s and early 1980s. Some of these systems have no original AT&T code but can still trace their ancestry to AT&T designs. These systems—largely commercial in nature—have been determined by
616-873: A misuse of their trademark. Their guidelines require "UNIX" to be presented in uppercase or otherwise distinguished from the surrounding text, strongly encourage using it as a branding adjective for a generic word such as "system", and discourage its use in hyphenated phrases. Other parties frequently treat "Unix" as a genericized trademark . Some add a wildcard character to the name to make an abbreviation like "Un*x" or "*nix", since Unix-like systems often have Unix-like names such as AIX , A/UX , HP-UX , IRIX , Linux , Minix , Ultrix , Xenix , and XNU . These patterns do not literally match many system names, but are still generally recognized to refer to any UNIX system, descendant, or work-alike, even those with completely dissimilar names such as Darwin / macOS , illumos / Solaris or FreeBSD . In 2007, Wayne R. Gray sued to dispute
SECTION 10
#1732773367846672-403: A new group – a "user private group" – for each user. Assuming that each user is the only member of its user private group, this scheme allows an umask of 002 to be used without allowing other users to write to newly created files in normal directories because such files are assigned to the creating user's private group. However, when sharing files is desirable, the administrator can create
728-631: A per-file all-user read-only attribute. NTFS implemented in Microsoft Windows NT and its derivatives, use ACLs to provide a complex set of permissions. OpenVMS uses a permission scheme similar to that of Unix. There are four categories (system, owner, group, and world) and four types of access permissions (Read, Write, Execute and Delete). The categories are not mutually disjoint: World includes Group, which in turn includes Owner. The System category independently includes system users. HFS , and its successor HFS+ , as implemented in
784-403: A permission is not set, the corresponding rights are denied. Unlike ACL-based systems, permissions on Unix-like systems are not inherited. Files created within a directory do not necessarily have the same permissions as that directory. Unix-like systems typically employ three additional modes. These are actually attributes but are referred to as permissions or modes. These special modes are for
840-784: A permissions system relatively advanced for a single-user OS. In AmigaOS 1.x, files had Archive, Read, Write, Execute and Delete (collectively known as ARWED) permissions/flags. In AmigaOS 2.x and higher, additional Hold, Script, and Pure permissions/flags were added. OpenHarmony operating system alongside its client side ecosystem in Oniro OS and HarmonyOS with HarmonyOS NEXT versions and also Linux-based openEuler server OS natively uses its Harmony Distributed File System (HMDFS) that supports access token manager ( role-based access control ) and Core File Kit API capability-based with granular permission management with exception to openEuler. Permissions on Unix-like file systems are defined in
896-579: A script named makedev or MAKEDEV to create all necessary devices in the directory /dev . It only makes sense on systems whose devices are statically assigned major numbers (e.g., by means of hardcoding it in their kernel module). Some other Unix systems such as FreeBSD use kernel-based device node management via devfs only and do not support manual node creation. mknod(2) system call and mknod(8) command exist to keep compatibility with POSIX, but manually created device nodes outside devfs will not function at all. The following prefixes are used for
952-426: A specific set of permissions. More technically, this is an octal representation of a bit field – each bit references a separate permission, and grouping 3 bits at a time in octal corresponds to grouping these permissions by user, group, and others. These are the examples from the symbolic notation section given in octal notation: Some systems diverge from the traditional POSIX model of users and groups by creating
1008-486: A variety of proprietary systems were developed based on it, including AIX , HP-UX , IRIX , SunOS , Tru64 , Ultrix , and Xenix . These largely displaced the proprietary clones. Growing incompatibility among these systems led to the creation of interoperability standards, including POSIX and the Single UNIX Specification . Various free, low-cost, and unrestricted substitutes for UNIX emerged in
1064-416: Is followed by a number uniquely identifying the particular device. For hard drives, a letter is used to identify devices and is followed by a number to identify partitions . Thus a file system may "know" an area on a disk as /dev/sda3 , for example, or "see" a networked terminal session as associated with /dev/pts/14 . On disks using the typical PC master boot record , the device numbers of primary and
1120-550: Is made up of many small, interchangeable components that can be added or removed as needed. This makes it easy to customize the operating system to suit the needs of different users or environments. The Open Group owns the UNIX trademark and administers the Single UNIX Specification, with the "UNIX" name being used as a certification mark . They do not approve of the construction "Unix-like", and consider it
1176-405: Is one that behaves in a manner similar to a Unix system, although not necessarily conforming to or being certified to any version of the Single UNIX Specification . A Unix-like application is one that behaves like the corresponding Unix command or shell . Although there are general philosophies for Unix design, there is no technical standard defining the term, and opinions can differ about
SECTION 20
#17327733678461232-514: Is read and written by the operating system and hardware. These together can be called device special files in contrast to named pipes , which are not connected to a device but are not ordinary files either. MS-DOS borrowed the concept of special files from Unix but renamed them devices . Because early versions of MS-DOS did not support a directory hierarchy, devices were distinguished from regular files by making their names reserved words that cannot be used as folder or file names; for example:
1288-439: Is that because block devices are buffered, the programmer does not know how long it will take before written data is passed from the kernel's buffers to the actual device, or indeed in what order two separate writes will arrive at the physical device. Additionally, if the same hardware exposes both character and block devices, there is a risk of data corruption due to clients using the character device being unaware of changes made in
1344-418: Is their ability to support multiple users and processes simultaneously. This allows users to run multiple programs at the same time and to share resources such as memory and disk space. This is in contrast to many older operating systems, which were designed to only support a single user or process at a time. Another important feature of Unix-like systems is their modularity . This means that the operating system
1400-629: The AVAILDEV CONFIG.SYS parameter that, if set to FALSE , makes these special names only active if prefixed with \DEV\ , thus allowing ordinary files to be created with these names. GEMDOS , the DOS-like part of Atari TOS , supported similar device names to DOS, but unlike DOS it required a trailing ":" character (on DOS, this is optional) to identify them as devices as opposed to normal filenames (thus "CON:" would work on both DOS and TOS, but "CON" would name an ordinary file on TOS but
1456-507: The Classic Mac OS operating systems, do not support permissions. macOS uses POSIX-compliant permissions, and supports them in both HFS+ and APFS . Beginning with version 10.4 ("Tiger"), it also supports the use of NFSv4 ACLs in addition to POSIX-compliant permissions. The Apple Mac OS X Server version 10.4+ File Services Administration Manual recommends using only traditional Unix permissions if possible. macOS also still supports
1512-530: The Open Group to meet the Single UNIX Specification and are allowed to carry the UNIX name. Most such systems are commercial derivatives of the System V code base in one form or another, although Apple macOS 10.5 and later is a BSD variant that has been certified, and EulerOS and Inspur K-UX are Linux distributions that have been certified. A few other systems (such as IBM z/OS) earned the trademark through
1568-692: The PC-E500 , PC-E500S etc. consists of a BASIC interpreter, a DOS 2-like File Control System (FCS) implementing a rudimentary 12-bit FAT -like filesystem, and a BIOS-like Input/Output Control System (IOCS) implementing a number of standard character and block device drivers as well as special file devices including STDO:/SCRN: (display), STDI:/KYBD: (keyboard), COM: (serial I/O), STDL:/PRN: (printer), CAS: (cassette tape), E:/F:/G: (memory file), S1:/S2:/S3: (memory card), X:/Y: (floppy), SYSTM: (system), and NIL: (function). Unix-like A Unix-like (sometimes referred to as UN*X or *nix ) operating system
1624-514: The 1980s and 1990s, including 4.4BSD , Linux , and Minix . Some of these have in turn been the basis for commercial "Unix-like" systems, such as BSD/OS and macOS . Several versions of (Mac) OS X/macOS running on Intel-based Mac computers have been certified under the Single UNIX Specification . The BSD variants are descendants of UNIX developed by the University of California at Berkeley, with UNIX source code from Bell Labs . However,
1680-542: The BSD code base has evolved since then, replacing all the AT&T code. Since the BSD variants are not certified as compliant with the Single UNIX Specification, they are referred to as "UNIX-like" rather than "UNIX". Dennis Ritchie , one of the original creators of Unix, expressed his opinion that Unix-like systems such as Linux are de facto Unix systems. Eric S. Raymond and Rob Landley have suggested that there are three kinds of Unix-like systems: Those systems with
1736-651: The Classic Mac OS's "Protected" attribute. Solaris ACL support depends on the filesystem being used; older UFS filesystem supports POSIX.1e ACLs, while ZFS supports only NFSv4 ACLs. Linux supports ext2 , ext3 , ext4 , Btrfs and other file systems many of which include POSIX.1e ACLs. There is experimental support for NFSv4 ACLs for ext3 and ext4 filesystems. FreeBSD supports POSIX.1e ACLs on UFS, and NFSv4 ACLs on UFS and ZFS. IBM z/OS implements file security using RACF (Resource Access Control Facility) The AmigaOS Filesystem, AmigaDOS supports
Device file - Misplaced Pages Continue
1792-524: The Folder Options control panel." Attempting to rename any file or folder using a reserved name silently reverts the object to its previous name (or "New Folder", "New Text Document", etc.), with no notification or error message. In Windows Vista and later, attempting to use a reserved name for a file or folder brings up an error message saying, "The specified device name is invalid." In some Unix-like systems, most device files are managed as part of
1848-512: The IDE devices are named /dev/wd0 , /dev/wd1 , etc. devfs is a specific implementation of a device file system on Unix-like operating systems, used for presenting device files. The underlying mechanism of implementation may vary, depending on the OS. Maintaining these special files on a physically-implemented file system such as a hard drive is inconvenient, and as it needs kernel assistance anyway,
1904-874: The POSIX chair Andrew Josey for the symbolic price of one dollar. There have been some activities to make Linux POSIX-compliant, with Josey having prepared a list of differences between the POSIX standard and the Linux Standard Base specification, but in August 2005, this project was shut down because of missing interest at the LSB work group. Some non-Unix-like operating systems provide a Unix-like compatibility layer , with varying degrees of Unix-like functionality. Other means of Windows-Unix interoperability include: File system permissions Most file systems include attributes of files and directories that control
1960-401: The POSIX.1-2017 standard, which uses three scopes or classes known as owner , group , and others . When a file is created its permissions are restricted by the umask of the process that created it. Files and directories are owned by a user. The owner determines the file's user class . Distinct permissions apply to the owner. Files and directories are assigned a group , which define
2016-488: The ability of users to read, change, navigate, and execute the contents of the file system. In some cases, menu options or functions may be made visible or hidden depending on a user's permission level; this kind of user interface is referred to as permission-driven . Two types of permissions are widely available: POSIX file system permissions and access-control lists (ACLs) which are capable of more specific control. The original File Allocation Table file system has
2072-672: The buffers of the block device. Most systems create both block and character devices to represent hardware like hard disks. FreeBSD and Linux notably do not; the former has removed support for block devices, while the latter creates only block devices. To get the effect of a character device from a block device on Linux, one must open the device with the Linux-specific O_DIRECT flag. Device nodes on Unix-like systems do not necessarily have to correspond to physical devices . Nodes that lack this correspondence are called pseudo-devices . They provide various functions handled by
2128-482: The case (e.g. on FreeBSD 5 and up). As with other special file types, the computer system accesses device nodes using standard system calls and treats them like regular computer files. Two standard types of device files exist; unfortunately their names are rather counter-intuitive for historical reasons, and explanations of the difference between the two are often incorrect as a result. Character special files or character devices provide unbuffered, direct access to
2184-406: The command ls -l , is symbolic notation . The first character of the ls display indicates the file type and is not related to permissions. The remaining nine characters are in three sets, each representing a class of permissions as three characters. The first set represents the user class. The second set represents the group class. The third set represents the others class. Each of
2240-1004: The concept of special files from Unix but renamed them devices . Because early versions of MS-DOS did not support a directory hierarchy, devices were distinguished from regular files by making their names reserved words . This means that certain file names were reserved for devices, and should not be used to name new files or directories. The reserved names themselves were chosen to be compatible with "special files" handling of PIP command in CP/M . There were two kinds of devices in DOS: Block Devices (used for disk drives) and Character Devices (generally all other devices, including COM and PRN devices). DOS uses device files for accessing printers and ports. Most versions of Windows also contain this support, which can cause confusion when trying to make files and folders of certain names, as they cannot have these names. Versions 2.x of MS-DOS provide
2296-464: The console device on DOS). In MiNT and MagiC , a special UNIX-like unified filesystem view accessed via the "U:" drive letter also placed device files in "U:\DEV". Using shell redirection and pipes, data can be sent to or received from a device. For example, typing the following will send the file c:\data.txt to the printer: PIPE, MAILSLOT, and MUP are other standard Windows devices. The 8-bit operating system of Sharp pocket computers like
Device file - Misplaced Pages Continue
2352-536: The degree to which a particular operating system or application is Unix-like. Some well-known examples of Unix-like operating systems include Linux and BSD . These systems are often used on servers as well as on personal computers and other devices. Many popular applications, such as the Apache web server and the Bash shell, are also designed to be used on Unix-like systems. One of the key features of Unix-like systems
2408-451: The fact that a character device for a piece of block-based hardware will typically require programs to read and write aligned blocks. Block special files or block devices provide buffered access to hardware devices, and provide some abstraction from their specifics. Unlike character devices, block devices will always allow the programmer to read or write a block of any size (including single characters/bytes) and any alignment. The downside
2464-407: The file's group class. Distinct permissions apply to members of the file's group. The owner may be a member of the file's group. Users who are not the owner, nor a member of the group, comprise a file's others class . Distinct permissions apply to others. The effective permissions are determined based on the first class the user falls within in the order of user, group then others. For example,
2520-424: The hardware device. They do not necessarily allow programs to read or write single characters at a time; that is up to the device in question. The character device for a hard disk, for example, will normally require that all reads and writes be aligned to block boundaries and most certainly will not allow reading a single byte. Character devices are sometimes known as raw devices to avoid the confusion surrounding
2576-518: The host OS at various nodes in the global file system tree. By restricting the device nodes populated into chroot instances of /dev , hardware isolation can be enforced by the chroot environment (a program can not meddle with hardware that it can neither see nor name—an even stronger form of access control than Unix file system permissions ). MS-DOS managed hardware device contention (see terminate-and-stay-resident program ) by making each device file exclusive open. An application attempting to access
2632-499: The idea arose of a special-purpose logical file system that is not physically stored. Defining when devices are ready to appear is not trivial. The devfs approach is for the device driver to request creation and deletion of devfs entries related to the devices it enables and disables. A device file is a reserved keyword used in PC DOS , TOS , OS/2 , and Windows systems to allow access to certain ports and devices. MS-DOS borrowed
2688-518: The names of some devices in the /dev hierarchy, to identify the type of device: Some additional prefixes have come into common use in some operating systems: The canonical list of the prefixes used in Linux can be found in the Linux Device List , the official registry of allocated device numbers and /dev directory nodes for the Linux operating system. For most devices, this prefix
2744-470: The operating system. Some of the most commonly used (character-based) pseudo-devices include: Additionally, BSD-specific pseudo-devices with an ioctl interface may also include: Nodes are created by the mknod system call . The command-line program for creating nodes is also called mknod . Nodes can be moved or deleted by the usual filesystem system calls ( rename , unlink ) and commands ( mv , rm ). Some Unix versions include
2800-429: The optional extended partition are numbered 1 through 4, while the indexes of any logical partitions are 5 and onwards, regardless of the layout of the former partitions (their parent extended partition does not need to be the fourth partition on the disk, nor do all four primary partitions have to exist). Device names are usually not portable between different Unix-like system variants, for example, on some BSD systems,
2856-427: The overall file, not only users in one class, the setuid attribute modifies the executable character in the triad for the user, the setgid attribute modifies the executable character in the triad for the group and the sticky or text attribute modifies the executable character in the triad for others. For the setuid or setgid attributes, in the first or second triad, the x becomes s and the - becomes S . For
SECTION 50
#17327733678462912-508: The status of UNIX as a trademark, but lost his case, and lost again on appeal, with the court upholding the trademark and its ownership. "Unix-like" systems started to appear in the late 1970s and early 1980s. Many proprietary versions, such as Idris (1978), UNOS (1982), Coherent (1983), and UniFlex (1985), aimed to provide businesses with the functionality available to academic users of UNIX. When AT&T allowed relatively inexpensive commercial binary sublicensing of UNIX in 1979,
2968-401: The sticky or text attribute, in the third triad, the x becomes t and the - becomes T . Here is an example: Another method for representing Unix permissions is an octal (base-8) notation as shown by stat -c %a . This notation consists of at least three digits. Each of the three rightmost digits represents a different component of the permissions: owner, group, and others. (If
3024-407: The three characters represent the read, write, and execute permissions: The following are some examples of symbolic notation: In some permission systems additional symbols in the ls -l display represent additional permission features: To represent the setuid , setgid and sticky or text attributes, the executable character ( x or - ) is modified. Though these attributes affect
3080-401: The user who is the owner of the file will have the permissions given to the user class regardless of the permissions assigned to the group class or others class. Unix-like systems implement three specific permissions that apply to each class: The effect of setting the permissions on a directory, rather than a file, is "one of the most frequently misunderstood file permission issues". When
3136-485: The word CON is a reserved word. These were chosen for a degree of compatibility with CP/M and are still present in modern Windows for backwards compatibility. Names are not case-sensitive, so "con", "Con", and "CON" are all invalid names. In Windows XP , entering "Con" into the Run command returns the error message, "This file does not have a program associated with it for performing this action. Create an association in
#845154