Unix

Introduction File systems are the backbone of every operating system, translating the abstract notion of “files” into concrete storage on disks, SSDs, or even network shares. While most users interact with files through simple operations—open, edit, delete—there exists a powerful, often under‑appreciated feature that lets you reference the same data from multiple locations: links. Two primary kinds of links dominate POSIX‑compatible systems: Hard links – multiple directory entries that point directly to the same inode (the underlying data structure representing a file). Soft links (also called symbolic links or symlinks) – special files that contain a pathname to another file. Understanding the nuances of hard and soft links is essential for system administrators, developers, and power users alike. Misusing them can lead to data loss, security vulnerabilities, or baffling bugs. Conversely, mastering them enables elegant solutions for backups, deployment pipelines, version control, and more. ...

Introduction If you have ever glanced at the output of ls -i or wrestled with an “inode exhausted” error, you have already encountered the world of inodes. Inodes (index nodes) are the invisible data structures that give Unix‑like operating systems the ability to store, locate, and manage files efficiently. While the concept is decades old, it remains central to modern Linux, BSD, and even some network file systems. This article dives deep into the anatomy, purpose, and practical implications of inodes. By the end, you will understand: ...

Introduction When you log into a Unix or Linux system over SSH, you’re essentially opening a session that is bound to a controlling terminal. As long as that terminal exists, the kernel delivers signals—most notably SIGHUP (hang‑up)—to every process that belongs to the session. If the terminal disappears (for example, you close your SSH client or lose network connectivity), the kernel sends SIGHUP to the foreground and background jobs, and many of those jobs terminate by default. ...

Introduction Process creation is one of the core building blocks of any operating system. In Unix‑like environments, the fork() system call has become the canonical way to spawn a new process that is a near‑identical copy of its parent. Although the concept is simple—“duplicate the current process”—the underlying mechanics are surprisingly intricate, involving memory management tricks, file descriptor duplication, signal handling, and careful bookkeeping by the kernel. This article dives deep into how fork() works, covering everything from the high‑level philosophy behind process creation to the low‑level kernel steps that make it possible. We’ll explore practical C code examples, compare fork() with related system calls (vfork(), clone(), posix_spawn()), discuss performance and security implications, and finish with a checklist of common pitfalls and debugging techniques. ...