The Newcastle Connection (or UNIX United ) was a software subsystem from the early 1980s that could be added to each of a set of interconnected UNIX-like systems to build a distributed system. The latter would be functionally indistinguishable, at both user- and system-level, from a conventional UNIX system. It became a forerunner of Sun Microsystems ' Network File System (NFS). The name derives from the research group at Newcastle University , under Brian Randell , which developed it.
35-474: The term "UNIX United" describes the scheme of combining the overall filesystems of the participating UNIX machines; "Newcastle Connection" describes the underlying communication layer which enables this. A UNIX United system constructed with the Newcastle Connection is functionally indistinguishable from a centralised UNIX system at the system-call level. In essence, the concept of the "parent directory"
70-456: A Cambridge Ring network. Subsequent implementations added support for other versions of UNIX (including BSD 4.2 and System V ), network technologies, protocols and hardware architecture ( VAX , Motorola 68000 ). Super-root (Unix) In a computer file system , and primarily used in the Unix and Unix-like operating systems , the root directory is the first or top-most directory in
105-455: A from "unix1" to "unix2" to sit alongside files b and c , example equivalent commands might be: It required no changes to the UNIX kernel. Rather, it ran in user-space, using a modified version of the C standard library of its day which was capable of recognising these new semantics. To a first approximation this was to recognise pathnames beginning with "/.." . A match would divert such
140-590: A contraction of the term index node and is commonly used in literature on the UNIX system". A file system relies on data structures about the files, as opposed to the contents of that file. The former are called metadata —data that describes data. Each file is associated with an inode , which is identified by an integer, often referred to as an i-number or inode number . Inodes store information about files and directories (folders), such as file ownership, access mode (read, write, execute permissions), and file type. The data may be called stat data, in reference to
175-497: A directory below the root directory. Normally, "/.." points back to the same inode as "/", however, under MUNIX [ de ] , this can be changed to point to a super-root directory, where remote trees can be mounted. If, for example, two workstations "pcs2a" and "pcs2b" were connected via "connectnodes" and "uunite" startup script, "/../pcs2b" could be used to access the root directory of "pcs2b" from "pcs2a". Under DOS , OS/2 , and Microsoft Windows , each partition has
210-478: A drive letter assignment (e.g. the C partition is labeled C:\ ) and there is no public root directory on it. On many Unixes , there is also a directory named /root (pronounced "slash root"). This is the home directory of the 'root' superuser . On many Mac and iOS systems this superuser home directory is /var/root . A home page 's URL usually points to the root of the respective website 's domain name . Inode The inode (index node)
245-502: A file system is created, some file systems allocate a fixed number of inodes. This means that it is possible to run out of inodes on a file system, even if there is free space remaining in the file system. This situation often arises in use cases where there are many small files, such as on a server storing email messages, because each file, no matter how small, requires its own inode. Other file systems avoid this limitation by using dynamic inode allocation. Dynamic inode allocation allows
280-471: A file system to create more inodes as needed instead of relying on a fixed number created at the time of file system creation. This can "grow" the file system by increasing the number of inodes available for new files and directories, thus avoiding the problem of running out of inodes. It can make sense to store very small files in the inode itself to save both space (no data block needed) and lookup time (no further disk access needed). This file system feature
315-457: A fixed-size inode table, but must store equivalent data in order to provide equivalent capabilities. Common alternatives to the fixed-size table include B-trees and the derived B+ trees . File names and directory implications: The operating system kernel's in-memory representation of this data is called struct inode in Linux . Systems derived from BSD use the term vnode (the "v" refers to
350-477: A hierarchy. It can be likened to the trunk of a tree , as the starting point where all branches originate from. The root file system is the file system contained on the same disk partition on which the root directory is located; it is the filesystem on top of which all other file systems are mounted as the system boots up. Unix abstracts the nature of this tree hierarchy entirely and in Unix and Unix-like systems
385-459: A library file even as another process is replacing that same file. This operation should be performed atomically , meaning it should appear as a single operation that is either entirely completed or not done at all, with no intermediate state visible to other processes. During the replacement , a new inode is created for the new library file , establishing an entirely new mapping. Subsequently, future access requests for that library will retrieve
SECTION 10
#1732891138268420-444: A reference through to the new software, which then used remote procedure calls to the remote machine. All other pathnames would simply go through to the local kernel as usual. (If the current working directory was itself remote, this needed to be taken into account.) It did, however, require that all software intended to use it, including shells, the "cp" command, etc. needed to be re-linked with this new library. Continuing one of
455-517: Is a data structure in a Unix-style file system that describes a file-system object such as a file or a directory . Each inode stores the attributes and disk block locations of the object's data. File-system object attributes may include metadata (times of last change, access, modification), as well as owner and permission data. A directory is a list of inodes with their assigned names. The list includes an entry for itself, its parent, and each of its children. There has been uncertainty on
490-418: Is called inlining. The strict separation of inode and file data thus can no longer be assumed when using modern file systems. If the data of a file fits in the space allocated for pointers to the data, this space can conveniently be used. For example, ext2 and its successors store the data of symlinks (typically file names) in this way if the data is no more than 60 bytes ("fast symbolic links"). Ext4 has
525-402: The stat system call that provides the data to programs. The inode number indexes a table of inodes on the file system. From the inode number, the kernel's file system driver can access the inode contents, including the location of the file, thereby allowing access to the file. A file's inode number can be found using the ls -i command. The ls -i command prints the inode number in
560-588: The Linux VFS, directory entry cache, also known as dentry or dcache, are cache entries used by the kernel to speed up filesystem operations by storing information about directory links in RAM . Historically, it was possible to hard link directories. This made the directory structure an arbitrary directed graph contrary to a directed acyclic graph . It was even possible for a directory to be its own parent. Modern systems generally prohibit this confusing state, except that
595-461: The Linux kernel mailing list about the reason for the "i" in "inode". In 2002, the question was brought to Unix pioneer Dennis Ritchie , who replied: In truth, I don't know either. It was just a term that we started to use. "Index" is my best guess, because of the slightly unusual file system structure that stored the access information of files as a flat array on the disk, with all the hierarchical directory information living aside from this. Thus
630-462: The file (via the inode) by any processes will now point to the new version of the library. Thus, making it possible to perform updates even when the library is in use by another process. One significant advantage of this mechanism is that it eliminates the need for a system reboot to replace libraries currently in use. Consequently, systems can update or upgrade software libraries seamlessly without interrupting running processes or operations. When
665-412: The file itself. This pointer is an integer called the i-number (for index number) of the file. When the file is accessed, its i-number is used as an index into a system table (the i-list ) stored in a known part of the device on which the directory resides. The entry found thereby (the file's i-node ) contains the description of the file. Additionally, Maurice J. Bach wrote that the word inode "is
700-433: The file to be moved or renamed even during read or write operations, thereby ensuring continuous access without disruptions. This feature—having a file's metadata and data block locations persist in a central data structure , irrespective of file renaming or moving—cannot be fully replicated in many non-Unix file systems like FAT and its derivatives, as they lack a mechanism to maintain this invariant property when both
735-465: The file's directory entry and its data are simultaneously relocated. In these file systems, moving or renaming a file might lead to more significant changes in the data structure representing the file, and the system does not keep a separate, central record of the file's data block locations and metadata as inodes do in Unix-like systems. inode file systems allow a running process to continue accessing
SECTION 20
#1732891138268770-423: The filename that was used to open it. When a program opens a file, the operating system converts the filename to an inode number and then discards the filename. As a result, functions like getcwd() and getwd() which retrieve the current working directory of the process, cannot directly access the filename. Beginning with the current directory, these functions search up to its parent directory , then to
805-441: The filesystem until the resources (disk space and blocks) freed by the unlinked file are deallocated or the file system is modified. Although an unlinked file becomes invisible in the filesystem, its deletion is deferred until all processes with access to the file have finished using it, including executable files which are implicitly held open by the processes executing them. It is typically not possible to map from an open file to
840-516: The first column of the report. On many older file systems, inodes are stored in one or more fixed-size areas that are set up at file system creation time, so the maximum number of inodes is fixed at file system creation, limiting the maximum number of files the file system can hold. A typical allocation heuristic for inodes in a file system is one inode for every 2K bytes contained in the filesystem. Some Unix-style file systems such as JFS , XFS , ZFS , OpenZFS , ReiserFS , btrfs , and APFS omit
875-400: The i-number is an index in this array, the i-node is the selected element of the array. (The "i-" notation was used in the 1st edition manual; its hyphen was gradually dropped.) A 1978 paper by Ritchie and Ken Thompson bolsters the notion of "index" being the etymological origin of inodes. They wrote: […] a directory entry contains only a name for the associated file and a pointer to
910-400: The kernel's virtual file system layer). The POSIX standard mandates file-system behavior that is strongly influenced by traditional UNIX file systems. An inode is denoted by the phrase "file serial number", defined as a per-file system unique identifier for a file. That file serial number, together with the device ID of the device containing the file, uniquely identify the file within
945-424: The newly installed version. When the operating system is replacing the file (and creating a new inode), it places a lock on the inode and possibly the containing directory. This prevents other processes from reading or writing to the file (inode) during the update operation, thereby avoiding data inconsistency or corruption. Once the update operation is complete, the lock is released. Any subsequent access to
980-416: The original name, not the inode (number). An inode may have no links. An inode without links represents a file with no remaining directory entries or paths leading to it in the filesystem. A file that has been deleted or lacks directory entries pointing to it is termed an 'unlinked' file. Such files are removed from the filesystem, freeing the occupied disk space for reuse. An inode without links remains in
1015-483: The parent of root is still defined as root. The most notable exception to this prohibition is found in Mac OS X (versions 10.5 and higher) which allows hard links of directories to be created by the superuser. When a file is relocated to a different directory on the same file system, or when a disk defragmentation alters its physical location, the file's inode number remains unchanged. This unique characteristic permits
1050-474: The parent's parent, and so on, until reaching the root directory . At each level, the function looks for a directory entry whose inode matches that of the directory it just moved up from. Because the child directory's inode still exists as an entry in its parent directory , it allows the function to reconstruct the absolute path of the current working directory . Some operating systems maintain extra information to make this operation run faster. For example, in
1085-439: The previous examples, the "cp" command attempts, as expected, to open the two files: Assuming the command has been relinked with the revised C-library, the first open() happens as normal on the local system. The second, however, is diverted into the "Newcastle Connection" software because of the filename's leading " /.. ". The original implementation at Newcastle was for UNIX V7 on a set of PDP-11 computers connected by
Newcastle Connection - Misplaced Pages Continue
1120-427: The root directory is denoted by the / (slash) sign. Though the root directory is conventionally referred to as / , the directory entry itself has no name – its path is the "empty" part before the initial directory separator character ( / ). All file system entries, including mounted file systems are "branches" of this root. In UNIX-like operating systems, each process has its own idea of what
1155-450: The root directory is. For most processes this is the same as the system's actual root directory, but it can be changed by calling the chroot system call . This is typically done to create a secluded environment to run software that requires legacy libraries and sometimes to simplify software installation and debugging. Chroot is not meant to be used for enhanced security as the processes inside can break out. Some Unix systems support
1190-435: The whole system. Within a POSIX system, a file has the following attributes which may be retrieved by the stat system call: Filesystems designed with inodes will have the following administrative characteristics: Files can have multiple names. If multiple names hard link to the same inode then the names are equivalent; i.e., the first to be created has no special status. This is unlike symbolic links , which depend on
1225-485: Was re-interpreted at the root of the filesystem, where it originally had no significant meaning, to mean "this directory is on a remote machine", similar to subsequent " Super-root (Unix) " usage. As a reminder, a typical single UNIX directory tree might resemble: UNIX United acts as an extra level above the / root. If the example machine is named "unix1", an overall UNIX United scheme with an additional second machine, "unix2", would look like: If we wish to copy file
#267732