Device file

Using standard system calls simplifies many programming tasks, and leads to consistent user-space I/O mechanisms regardless of device features and functions.

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.

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 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).

A variety of device driver semantics are implemented in Unix and Linux concerning concurrent access.

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.

They do not necessarily allow programs to read or write single characters at a time; that is up to the device in question.

Most systems create both block and character devices to represent hardware like hard disks.

Nodes can be moved or deleted by the usual filesystem system calls (rename, unlink) and commands (mv, rm).

It only makes sense on systems whose devices are statically assigned major numbers (e.g., by means of hardcoding it in their kernel module).

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.

[1] Because early versions of MS-DOS did not support a directory hierarchy, devices were distinguished from regular files by making their names reserved words.

[12] The reserved names themselves were chosen to be compatible with "special files" handling of PIP command in CP/M.

In MiNT and MagiC, a special UNIX-like unified filesystem view accessed via the "U:" drive letter also placed device files in "U:\DEV".

For example, typing the following will send the file c:\data.txt to the printer: PIPE, MAILSLOT, and MUP are other standard Windows devices.

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).