Filesystem & Files
Filesystem hierarchy, daily navigation, find & grep, and permissions done; hard vs. soft links and archives still to go.
What's done so far
- A1 — Filesystem hierarchy. What actually lives in /proc, /sys, /dev, /etc, /var, /usr.
- A2 — Daily navigation. ls -la, cd, cp, mv, rm -r, mkdir -p, globbing.
- A3 — find & grep. Finding by name/type vs. searching file contents.
- A4 — Permissions. rwx triplets, chmod octal + symbolic, chown, the sticky bit.
The filesystem hierarchy
| Path | What it actually is |
|---|---|
/proc | A virtual, in-memory view of running processes and kernel state — nothing here is on disk, it's generated on read. |
/sys | The kernel's device model exposed as files. kobject/kref/uevent live under here, though the deep mechanics of that are pulled-forward Phase 4/5 material — taught conceptually for now, not trace-tested at that depth. |
/dev | Device nodes — also virtual (devtmpfs, RAM-backed), same family as /proc and /sys. What actually differs is role, not "virtual-ness": these files are handles to hardware, not a metadata dump. Nodes appear either at boot or dynamically at hotplug — not only at boot, which was my first framing. |
/etc | System-wide configuration. One distinction that came up live while covering it: insmod never reads anything under /etc/modprobe.d/ — only modprobe does. |
/var | Variable, changing data — logs, spool files, anything that grows while the system runs. |
/usr | Installed software and its data — not "userspace files" in some abstract sense, which was my first, wrong framing of it. Passed on the second attempt once corrected. |
The slip that kept recurring across this chapter: saying "character/block driver" when I meant "character/block device." The node in /dev classifies what kind of device it is — the driver is the code behind it, a different thing entirely.
Permissions
chmod 750 file # owner: rwx, group: r-x, other: ---
chmod u+x,g+x file # symbolic mode — a class letter (u/g/o/a) is required
chmod +x file # no class letter given: defers to umask, NOT the same as a+xTwo things I had backwards at first. chmod +x with no explicit class letter isn't shorthand for a+x — it defers to the process's umask, and I only really believed that once it was run live under umask 011 and granted owner-execute but not group/other. And permission checks aren't "any matching bit passes": the kernel checks owner, then group, then other, in that order, and the first class that matches is the one that governs — even if a later class would technically have been more permissive.
The sticky bit shows up as a lowercase t in /tmp's permission string — sticky and execute both set on the same bit position; an uppercase T would mean sticky without execute. Sticky on a world-writable directory means each user can delete only their own files inside it, which is exactly why /tmp needs it.
Notes from readers
Comments — via GitHub