A FILE is a named collection of related information on secondary storage. To the OS it is a sequence of bytes; the STRUCTURE is imposed by the application. FILE ATTRIBUTES (metadata): name the human-readable identifier identifier a unique internal number (the inode number) type regular, directory, symlink, device, socket, FIFO location a pointer to the data blocks size current size in bytes protection owner, group, permission bits timestamps created, last modified, last accessed link count how many directory entries refer to it FILE OPERATIONS — the six primitives: create, write, read, reposition (seek), delete, truncate plus open() and close(), which manage in-memory state. OPEN-FILE STATE the OS keeps per open file: file pointer current read/write position open count how many processes have it open disk location cached, to avoid re-reading the inode access rights what THIS opener may do The open count is why closing does not immediately release resources: the file is freed only when the last opener closes. FILE TYPES in UNIX, visible as the first character of `ls -l`: - regular file c character device (terminal) d directory b block device (disk) l symbolic link p named pipe (FIFO) s socket "Everything is a file" is the design decision that lets read() and write() work on all of them. It is why you can `cat /dev/urandom`, and why a socket has a file descriptor.

A DIRECTORY is a file whose contents are a table mapping NAMES to inode numbers. That is all it is. name inode ───────────────────── . 10942023 (itself) .. 10940001 (parent) original.txt 10942023 notes.md 10942100 Because a directory stores only names and inode numbers, the FILE METADATA lives in the inode, not the directory. One direct consequence: renaming a file rewrites one directory entry and touches no file data, which is why `mv` within a filesystem is instantaneous regardless of file size. DIRECTORY STRUCTURES, historically: SINGLE-LEVEL one directory for everything ✗ name collisions; unusable with many users TWO-LEVEL one directory per user ✗ no grouping within a user's files TREE the standard: directories nest arbitrarily ✔ path names, working directory, grouping ACYCLIC GRAPH allows SHARING — one file in two directories → this is what hard links provide GENERAL GRAPH cycles permitted ✗ traversal may loop forever; reference counting cannot reclaim a cycle, so garbage collection would be needed → which is why UNIX FORBIDS hard links to directories PATH NAMES: ABSOLUTE from the root: /home/manish/notes.md RELATIVE from the cwd: ../notes.md · "." is the current directory, ".." the parent · both are REAL entries in every directory, which is why an empty directory has a link count of 2 — its own "." plus the parent's entry naming it

# Verified on APFS, macOS. Block size 4096 bytes.
echo "hello world" > original.txt
ln    original.txt hardlink.txt     # hard link
ln -s original.txt symlink.txt      # symbolic link

stat -f "%N  inode=%i links=%l size=%z blocks=%b type=%HT"      original.txt hardlink.txt symlink.txt
original.txt  inode=10942023 links=2 size=12 blocks=8 type=Regular File
hardlink.txt  inode=10942023 links=2 size=12 blocks=8 type=Regular File
symlink.txt   inode=10942026 links=1 size=12 blocks=0 type=Symbolic Link

# Now DELETE the original and see what survives.
rm original.txt
cat hardlink.txt
hello world          <- STILL READABLE
cat symlink.txt
cat: symlink.txt: No such file or directory   <- BROKEN

READ THE MEASURED OUTPUT CAREFULLY — it contains the whole distinction: original.txt and hardlink.txt share INODE 10942023. They are not "a file and a link to it"; they are TWO NAMES FOR ONE FILE. Neither is the original. `links=2` records that two directory entries point at this inode. symlink.txt has its OWN inode (10942026) and `blocks=0`. It is a tiny file whose CONTENTS are the text "original.txt" — which is why its size is 12 bytes, the length of that name. WHY THE HARD LINK SURVIVED DELETION: `rm` does not delete files. It removes a DIRECTORY ENTRY and decrements the inode's link count. before rm: links = 2 after rm: links = 1 → inode still in use, data intact The inode and its blocks are freed only when the count reaches 0 AND no process has the file open. THE PRODUCTION CONSEQUENCE: if a process still holds a deleted file open, the space is NOT reclaimed. `df` shows the disk full while `du` finds nothing large — the classic disk-full mystery. `lsof | grep deleted` finds it, and only restarting the process frees the space. WHY THE SYMLINK BROKE: It stores a PATH, resolved at every access. The path no longer names anything, so resolution fails. A symlink can even point at something that never existed. THE COMPARISON: HARD LINK SYMBOLIC LINK points to the INODE a PATH (text) own inode NO — shares it YES survives target YES NO (dangles) deletion cross-filesystem NO YES to a directory FORBIDDEN (cycles) allowed extra disk space none one small file cost per access none a path resolution WHY HARD LINKS CANNOT CROSS FILESYSTEMS: a directory entry stores only an inode NUMBER, meaningful within one filesystem. Inode 10942023 exists on many filesystems and means something different on each. WHY HARD LINKS TO DIRECTORIES ARE FORBIDDEN: they would create a general graph with cycles. `find` would loop forever and reference counting could never free a cycle. The exceptions "." and ".." are created by the kernel, which handles them specially.

ACCESS METHODS: SEQUENTIAL read/write in order, with a rewind · the natural model for tapes, pipes, and most file processing DIRECT (random) read/write block n directly · offset = record_number × record_size INDEXED an index maps a KEY to a block, then read it · this is what a database index is PROTECTION — UNIX permission bits: r w x for owner / group / others read(4) write(2) execute(1) 755 = rwxr-xr-x owner all, others read+execute 644 = rw-r--r-- owner read/write, others read 600 = rw------- owner only ON A DIRECTORY the bits mean something different, and this is regularly examined: r LIST the entries (ls) w create/delete entries within it x TRAVERSE it — enter it, or resolve a path through it CONSEQUENCE 1: mode `--x` on a directory lets you access a file whose name you already know, without being able to LIST the directory. That is how a shared upload directory hides other users' filenames. CONSEQUENCE 2: to DELETE a file you need write permission on its DIRECTORY, not on the file. Deletion removes a directory entry, so the directory is what is modified. That surprises people, and it is why the STICKY BIT exists — on /tmp (mode 1777) it restricts deletion to each file's owner despite the directory being world-writable. SPECIAL BITS: setuid (4000) run with the OWNER's privileges — how `passwd` edits /etc/shadow setgid (2000) run with the group's privileges; on a directory, new files inherit the group sticky (1000) on a directory, only the owner may delete their own files