25-Comp-A5 Operating Systems · December 2013
Nivaar worked solution (AI-drafted; not reviewed by a licensed engineer)
Question text not reproduced: the examination questions are © Engineers and Geoscientists BC. Open the official past paper (linked at the top of this page) to read the question, then follow the worked solution below.
(a) A link is a directory entry that lets a single physical file appear under more than one path name — a hard link creates a second directory entry that refers directly to the same underlying file identity (e.g. the same inode and data blocks), while a symbolic (soft) link is a special file whose content is simply the path name of the target, resolved indirectly at access time. Links are the mechanism that turns a strict directory TREE (where every file has exactly one parent) into an acyclic-graph directory, which is what actually enables file sharing: several users, or several directories belonging to one user, can each reach one physical copy of a file through their own path, and any edit made via one path is immediately visible via every other path, since there is only ever one copy of the underlying data. This avoids the storage waste and consistency risk of maintaining duplicate copies. Deletion problems arise specifically because a shared file now has multiple owners of its existence: if the system naively deletes the underlying file the moment ANY ONE directory entry pointing to it is removed, every OTHER hard link instantly becomes a dangling reference to freed disk blocks that may already have been overwritten by a new file — a serious correctness hazard. The standard fix is reference counting: the file's metadata (inode) keeps a count of how many hard links currently point to it; deleting a directory entry only decrements the count, and the disk blocks are only actually reclaimed when the count reaches zero. Symbolic links complicate this further because they do NOT participate in the reference count at all — deleting the target file (when the hard-link count reaches zero) silently leaves any symbolic links pointing at it "dangling" with no automatic notification, which is a real and commonly-encountered failure mode (e.g. a broken shortcut) distinct from the hard-link case.
(b) Controlling file access is essential on any multi-user system because storage is shared among mutually untrusting (or at least mutually independent) users and processes: without protection, any user's process could read confidential data belonging to another user, or corrupt/delete another user's files, whether through a genuine bug (a wrong path, a runaway script) or deliberate malice. Access control provides confidentiality (only authorized users may read), integrity (only authorized users may modify or delete) and controlled sharing (a user can deliberately grant specific others exactly the access intended, no more). Two standard methods: (1) Owner/group/other permission bits (the classical UNIX model): each file carries three permission triples (read/write/execute) for its owning user, its owning group, and everyone else; the system checks the requester's identity against these three categories in order and applies the FIRST matching category's permissions. This is compact (a fixed few bits per file, independent of how many users exist) and fast to check, but coarse-grained — it cannot grant one specific OTHER user (who is not in the file's group) an exception without creating or joining a whole new group. (2) Access control lists (ACLs): each file instead carries an explicit list of (user-or-group, permission-set) pairs, checked by walking the list for a matching entry; this gives fully general per-user, per-permission control at the cost of a variable-length structure per file (more storage, slower lookup as the list grows) and more complex maintenance when a user's organizational role changes (every file they were individually granted access to must be located and updated). Both methods rely on the OS trusting the process's claimed identity (established at login/authentication) as the basis for every subsequent access check.
