Linux File System — Inodes, File Types, Permissions and Links

5.1 Inodes and File Identity

In Linux every file system object — whether it appears as a regular file or as a directory — is identified inside the kernel by a unique integer called the inode number. An inode is the on-disk data structure that stores the metadata for one object: its type, permissions, owner, group, size, timestamps, block pointers and link count. The directory entry you see by name is only a pointer that maps a human-readable name to that inode. Two different names can point to the same inode, and deleting a name only removes one pointer until the link count drops to zero.

Think of the inode as the identity card of a file and the name as a label stuck on the card. You can peel off the label and stick a new one on, but the card stays the same. That mental model explains why renaming a file, changing its permissions, or editing its contents does not give it a new identity, unless you create a genuinely new object.

Real-world: every tool that walks the file system — backup software, package managers, indexing services — relies on inode numbers to detect when the same underlying object appears in two places without copying data. Build systems such as make and backup tools such as rsync compare inode numbers and timestamps to avoid copying a file that is already present under a second name.

5.1.1 Mathematical View of the Inode Table

The session describes the inode number as the first column of a long listing. There is no deep formula here, but it helps to see the relation as a mapping.

The file system maintains a table where

$$\text{name}\stackrel{\text{directory entry}}{\to }\text{inode number}\in \mathbb{N}\stackrel{\text{inode table}}{\to }\text{metadata + block pointers}$$

where $\text{inode number}$ is a positive integer, $\mathbb{N}$ is the set of natural numbers, and the final block pointers locate the physical data on disk. The verbal description preserved from the session is: "Inode number is a unique number which will help me identify the file."

5.1.2 Displaying Inode Numbers — ls -i and ls -li

Two small options control what ls shows:

• ls -i — show only the inode number and the name.
• ls -li or equivalently ls -i -l — show the long listing with the inode number as the added first column.
• ls -l alone — long listing without inode numbers.

The i stands for inode — the first letter of the word. A common moment of confusion in the session was to read i as something else; the correction is that i always means inode in this context.

A typical ls -li line looks like (values are examples):

3277256 -rw-rw-r-- 1 owner group 0 May 20 12:00 paper.doc

Here 3277256 is the inode, -rw-rw-r-- encodes type and permissions, 1 is the link count, owner and group follow, 0 is size in bytes, then date, time and name.

For a directory the size field behaves differently — directories report the file system block size, normally $4096$ bytes.

5.1.3 Creating Paths and Observing New Inodes

Creating always allocates a new inode. Demonstrations in the session used:

• mkdir dir — make one directory in the current directory. Fails with "No such file or directory" if a parent in the path does not exist.
• mkdir -p bits/Goa — the -p flag means "make parents as needed": every missing directory in the path is created. This flag is essential when you want to build a deep hierarchy in one command.
• touch paper.doc — create an empty regular file. A freshly created file shows size $0$ and the current date and time.

After each creation, ls -li shows a fresh inode. Examples noted were 3277256 for a file named paper.doc and 327265 for a directory — concrete proof that files and directories each receive their own inode from the same number space.

Visual intuition: picture a directory as a two-column sheet — left column names you read, right column small integers. The -i flag unhides that right column. A second sheet, the inode table, lists those integers in order, each row holding the ten-character type and permissions, owner, group, size, three timestamps, link count and a list of disk block addresses. Looking up a name is two hops: name to integer, integer to row.

5.1.4 Worked Examples

3277256  paper.doc
327265   sample/

5.1.5 Student Questions and Answers

5.2 The Long Listing — What Every Column Means

The long listing is the primary way to read file metadata without opening the inode directly. ls -l prints one line per entry; ls -li prepends the inode. Every column has a fixed meaning, and the session went column by column so that later discussions of permissions, links and sizes would make sense.

5.2.1 Column by Column Anatomy

For a line produced by ls -li, reading left to right:

1. Inode number — integer identifier, present only with -i.
2. Type and permission field — ten characters, e.g., -rw-rw-r-- or drwxr-xr-x. Character one is the file type; characters two through ten are the permission triplets.
3. Link count — integer $\ge 1$. For regular files it counts hard links; for directories it counts internal references including . and ...
4. Owner — account name that owns the object (st_uid mapped to a name).
5. Group — group name to which the owner belongs at creation (st_gid mapped to a name). In the demonstration each user was placed in a private group, so owner and group often matched at first. Listing another location where files belonged to different users showed this field changing.
6. Size — in bytes for regular files (st_size); the file system block size $4096$ for a freshly created empty directory. A directory at $4096$ does not mean it contains $4096$ bytes of user data — it is the space taken by the directory structure itself.
7. Modification date and time — month, day, clock time of the last content change (mtime).
8. Name — the directory entry that points to the inode.

The session emphasized that even directories are treated as files in Linux, so their name field is not a special case — it is the same final column.

5.2.2 The Ten-Character Type and Permission Field

This string has length ten. Position one encodes type; positions two to ten encode permissions. Counting them helps avoid confusion:

position: 1  2 3 4  5 6 7  8 9 10
example:  -  r w -  r w -  r - -
meaning: type  user   group  others

The nine permission characters are grouped as three triplets: user (owner), group, others. Each triplet contains r, w, x or - in that order. A dash in positions two through ten means that particular permission is absent, which is distinct from the dash in position one that means "regular file".

Visual intuition: picture the ten-character field as ten little lamps. Lamp 1 colour tells the object family (-, d, c, b, l, p, s). Lamps 2–4 light r, w, x for the owner, 5–7 for the group, 8–10 for others. A dark lamp (-) is simply off. Example drwxr-xr-x lights all three for owner, r-x for group, r-x for others — a typical directory.

5.2.3 Owner, Group, Size and Timestamps in Depth

Owner and group. At creation the owner is the effective user who ran the creation command; the group is that user's primary group. Because the demonstration system created each user in a separate group, ls -l initially showed the same string in both columns. Moving to a shared area with files created by other accounts made the distinction visible: owner changed, group changed, and the permission triplets then governed who could do what. Under the surface these are numeric IDs st_uid and st_gid looked up in /etc/passwd and /etc/group for display.

Size. For a regular file, size is the logical byte count (st_size). For an empty file created with touch, it is 0. For a directory it is almost always 4096, the allocation unit for the directory's own table of names. A follow-up example showed three regular files inside a directory, each with its own small size (e.g., 12, 45, 120), while the directory entry itself still reported 4096. Writing more entries into the directory can later grow it to 8192, but never shrink it to reflect user data size.

Date, time and name. The timestamp shown by default is the last content modification time (mtime). Other timestamps exist — access time (atime) and change time (ctime) — and are discussed in 5.7. The final column is always the name that maps to the inode. Even directories use the same final column; the type character is what tells you it is a container.

5.2.4 Worked Examples

5.2.5 Student Questions and Answers

5.3 File Types — The First Character

The first character of the ten-character field classifies the object. Linux exposes many kinds of objects through the same file system interface, so learning this field lets you distinguish what you are looking at without opening it.

5.3.1 Regular Files and Directories

• - — regular file. Any file created with touch, an editor, a compiler output, or a downloaded document counts as regular. Text files with readable characters and binary executables both show - — the system does not distinguish them by type, only by content. A cat of a binary such as a command in the system area produces unreadable bytes, confirming that - covers both readable and non-readable contents. Executable programs are still regular files; they simply carry x in their permission triplet so the kernel will try to run them.
• d — directory. A container for names that point to inodes. Real-world: a folder that can hold any number of files and subdirectories. Its x permission means you may traverse it with cd.

The two most common types you will see day to day are - and d, and the session noted they are expected to dominate any long listing. In a typical home directory, 90 percent of lines show one of these two.

5.3.2 Device Files — Character (c) and Block (b)

To see the rarer types, the session listed /dev, the directory that exposes hardware:

• c — character device file. Data moves as a stream of characters, one at a time, with no block buffering. Examples discussed were serial ports, parallel ports, terminals identified as tty (tty0, tty1, ttyS0), pseudo-terminals pty, and the console. Because they transmit character by character, they are called character devices. Reading them yields a stream; seeking is often not allowed.
• b — block device file. Data moves in fixed-size blocks, typically 512 or 4096 bytes, with kernel buffering. Examples were disks shown as sda, sda1, sda2 and loop devices loop0. Hard disks are the canonical block device: the file system reads and writes blocks, not single characters. Block devices support random access by block number.

Running ls -li /dev showed a striking difference: inode numbers for device nodes were very small (two or three digits such as 14 for console, 5 for tty) compared with six- or seven-digit inodes for user-created files (e.g., 3277256). That pattern reflects early allocation of device inodes at system install versus dynamic allocation for user data. The ls -l size column for devices instead showed 5, 1 style major-minor pairs.

5.3.3 Symbolic Links, Named Pipes and Sockets

• l — symbolic link (also called soft link). Shown as l in the type field and usually displayed as name -> target with a distinct color. A symbolic link is a tiny file whose content is the path to another object. Real-world: the Windows shortcut is the closest analogy; l in the type field is the L you may see in some fonts. Its size is the length of the target path.
• p — named pipe (FIFO). Created with mkfifo for inter-process communication where one process writes and another reads in first-in first-out order. The p type appears only when a pipe file is created; it has no persistent presence in /dev by default.
• s — socket (Unix domain socket). Created by system services for communication between processes, often in /run or /tmp. Used in networking code and desktop services. Like p, it appears where a program creates it.

The session noted that a pipe socket file and a named pipe file are tied to inter-process mechanisms: named pipes, regular pipes, shared memory and sockets are different ways two otherwise isolated processes can exchange data, a topic returned to in later courses on network programming. No p or s entry was found in /dev during the live listing, which is normal — they appear where programs create them, not as permanent device nodes.

5.3.4 Exploring /dev and Capturing Output with Redirection

The session turned the /dev listing into a small exercise in redirection:

ls -li /dev > output.txt

Here > is the output redirection operator: the standard output of ls -li /dev is written into the regular file output.txt instead of the terminal. After the command, cat output.txt or ls -l output.txt confirms the capture, including the small inode numbers at the left and the mixed type characters c, b, l throughout. If output.txt already existed it is truncated first; >> would append instead.

A follow-up discussion captured two device-oriented views:

• Character devices such as tty and ports appeared as c with major-minor numbers.
• Block devices such as sda and sda1 appeared as b with major-minor numbers and small inodes.

These examples made clear that the file system is not only for user documents — it is also the uniform interface to hardware. Systems code, drivers and containers all rely on that uniformity.

5.3.5 Student Questions and Answers

5.4 File Permissions — rwx for User, Group and Others

Every file system object carries nine permission bits that decide who can read, write and execute it. Those bits are shown as nine characters grouped into three triplets, and the session spent substantial time decoding them because permission errors are the most common source of "permission denied" surprises.

5.4.1 Meaning of r, w and x

• r — read. If r is present in your triplet, you can list a directory or view a file's contents. Without r, cat file fails with permission denied. For a directory, r lets you list names inside; you still need x to enter.
• w — write. If w is present, you can modify the object's contents. For a file this means editing or appending; for a directory it means creating or deleting names inside. You can delete a file from a directory if you have w on the directory, even without w on the file itself.
• x — execute. If x is present on a regular file, you can run it as a program (./script.sh). If x is present on a directory, you can traverse it (enter it with cd or pass through it to a subpath). A normal text file such as output.txt or sample.txt usually shows - in the x position because the system treats it as data, not code. Trying to ./output.txt fails either from missing x or because the content is not executable code.

A dash - inside the nine slots always means "this permission is not granted" and should not be confused with the leading dash that means "regular file".

5.4.2 The Three Triplets — User, Group, Others

Reading the permission string from left to right after the type character:

-rwx rwx rwx
  ^   ^   ^
 user group others
 chars 2-4 chars 5-7 chars 8-10

• User (owner) — the first triplet (characters 2–4). Controls what the owning account can do.
• Group — the second triplet (characters 5–7). Controls what members of the file's group can do. In the demonstration each user started in a private group, but the concept allows a project group where several accounts share one group entry.
• Others — the third triplet (characters 8–10). Controls what everyone else can do. Real-world: this is how a file shared on a lab machine can be made readable campus-wide while remaining writable only to the owner.

For output.txt the session noted permissions rw- rw- r--. The owner can read and write, group members can read and write, others can only read. No triplet contained x because the file was plain text. The numeric view of that same string is 664 ( $6=4+2$, $4$ ).

Visual intuition: sketch three vertical columns labeled User, Group, Others, each with three rows r, w, x. A tick means the lamp is lit, - means dark. For rw-rw-r-- the User column has ticks on r and w, Group on r and w, Others on r alone.

5.4.3 Worked Examples — Reading Permission Strings

5.4.4 Industry and Pedagogical Notes

Real-world: in a team the second triplet becomes important. You can place all teammates in one group (groupadd team; usermod -aG team alice) and grant that group rw- on shared source files while leaving others at r-- or ---. The third triplet is then the public boundary. Platform teams set home directories to 750 (others none) and shared docs to 664 so the semester project passes permissions review.

The session flagged the permission decode as examination-relevant: being able to translate a ten-character string into type plus three triplets, and then into who can do what, was presented as a core skill. Examiners often give a string and ask "may user X run cat?" — you answer by picking the right triplet first.

5.4.5 Student Questions and Answers

5.5 Changing Permissions — Absolute (Octal) Mode

Permissions are not fixed at creation. The command that changes them is chmod, short for "change mode". The absolute mode sets all nine bits at once using three octal digits.

5.5.1 chmod Syntax and Who Can Run It

The general absolute form is:

chmod permissions file-or-dir

where permissions is three octal digits (examples: 000, 640, 755) and file-or-dir is the target. An example covered was chmod 000 more.txt to strip all rights. Each digit is base eight; the valid range is 0 to 7 only.

Only two actors are allowed to run this command on a file:

• The owner of the file (st_uid matches your effective UID).
• The superuser (root, UID 0 with elevated privileges).

Anyone else who tries to change permissions will receive chmod: changing permissions of 'file': Operation not permitted, even if they can read the file. Ownership is checked before the bits are touched.

5.5.2 Octal Mapping — r = 4, w = 2, x = 1

Each triplet maps to a single octal digit $0$ through $7$ by weighting the bits:

$$\text{octal digit}=4\cdot r+2\cdot w+1\cdot x$$

where $r,w,x\in \{0,1\}$ indicate absence or presence of that permission, verbalized in the session as "one and one and one" for a full rwx triplet.

Concrete binary to octal table:

The digit 7 comes from $4+2+1=7$. The digit 6 comes from $4+2+0=6$. The digit 4 is $4+0+0=4$. The digit 1 is $0+0+1=1$.

The three octal digits are ordered as $\text{user}\text{group}\text{others}$. So 741 means:

$$7\text{ for user}=rwx,4\text{ for group}=r--,1\text{ for others}=--x$$

The session repeatedly stressed that the value is written in octal (base eight), not binary. A question about whether binary strings like 100 could be typed directly was tested and the answer was no — chmod 100 is read as octal digits, and a mode such as 100 means $1$ $0$ $0$, not binary one-zero-zero. An attempt to give a binary string as an octal argument produced "invalid mode". The correct habit is to compute each digit $0$-$7$ from rwx and then write three digits left to right as user, group, others.

Visual intuition: sketch three rows user, group, others, each with three boxes r w x. Tick the boxes you want, read tick as 1, compute $4r+2w+1x$ per row, write the three results in order. Ticks 111, 100, 001 become 7, 4, 1.

5.5.3 Worked Examples — Step by Step

chmod 000 more.txt
ls -l more.txt  -->  ----------  (all dashes in permission slots)

chmod 700 more.txt
ls -l more.txt  -->  -rwx------ 

chmod 760 more.txt
ls -l more.txt  -->  -rwxrw---- 

chmod 741 more.txt
ls -l more.txt  -->  -rwxr----x

chmod 666 more.txt
ls -l more.txt  -->  -rw-rw-rw-

chmod 774 more.txt
ls -l more.txt --> -rwxrwxr--

5.5.4 Common Pitfall — Binary vs Octal

5.5.5 Student Questions and Answers

5.6 Changing Permissions — Relative (Symbolic) Mode

The absolute mode rewrites all three digits. The relative mode, also called symbolic mode, is finer: it adds or removes one permission for one category at a time, leaving other bits untouched. Learners found this style more readable for small adjustments.

5.6.1 Syntax — Category, Operation, Permission

The pattern is:

chmod category operation permission file

overlaid on the session's description as category $+-$ permission:

• Category (who): u user, g group, o others, a all. Combinations like ug, go, uo are allowed. a is shorthand for ugo — all three categories together.
• Operation: + add permission, - remove permission, = set exactly (mentioned but not the focus; the session emphasized + and - which are idempotent).
• Permission: r read, w write, x execute.

So chmod u+rwx more.txt reads as "for user, add read, write and execute". chmod g+r more.txt reads as "for group, add read". chmod o+x more.txt reads as "for others, add execute". You can combine permissions: u+rwx equals u+r,u+w,u+x in one token.

5.6.2 Worked Examples — Incremental Construction

chmod u+rwx more.txt
ls -l more.txt --> -rwx------   (u 7, g 0, o 0 = 700 equivalent)

chmod g+r more.txt
ls -l more.txt --> -rwxr-----   (u 7, g 4, o 0 = 740 equivalent)

chmod o+x more.txt
ls -l more.txt --> -rwxr----x   (u 7, g 4, o 1 = 741)

chmod a+rwx more.txt
# equivalent to chmod ugo+rwx more.txt
ls -l more.txt --> -rwxrwxrwx  (777)

chmod a-rwx more.txt
ls -l more.txt --> ----------  (000)

chmod ugo+r more.txt   # order ugo, goU, etc. does not matter
ls -l more.txt --> -r--r--r--  (444)
chmod a+x more.txt
ls -l more.txt --> -r-xr-xr-x  (555, r-x per triplet)

5.6.3 Adding Versus Removing and Category Combinations

• chmod g+w file — add write to group, leave user and others untouched. rw- rw- r-- (664) becomes rw- rwx r--? Actually only group w already present, so no change; from r-- r-- r-- it would become r-- rw- r--.
• chmod o-r file — remove read from others if present; no error if r was already absent. From rwxrwxrwx it becomes rwxrwx--x.
• chmod ug+r file — add read to both user and group in one command.
• chmod og-x file — remove execute from others and group together.

The session illustrated that the category letters can appear in any order: ugo+r and ogu+r have the same effect. The permission letters can also be combined (rwx), so u+rwx is the same as u+r,u+w,u+x in sequence. You can chain clauses comma-separated: chmod u+rwx,g+rw,o+r file mixes who gets what in one call.

Real-world: a team review workflow was sketched: create source with u+rwx, give reviewers g+rw so they can read and annotate, and keep o+r or o+x minimal for managers who only need to run the built output. Release then uses o-rwx to close visitor access quickly without recomputing user and group.

5.6.4 Interaction Between Absolute and Relative Modes

A practical tip given was to start new shared files with a sensible absolute default (often 664 for data, 755 = rwxr-xr-x for directories or scripts) and then fine-tune with relative operations. Absolute mode is faster when you know the final pattern; relative mode is safer when you only want to add or remove one bit without risking overwriting other bits you intended to keep. Both were demonstrated on the same more.txt file so learners could see the listing converge to identical results from either path.

Comparison in one view:

The session's advice: set the baseline with numbers, polish with symbols — numbers for known final states, symbols for live fixes during a lab.

5.6.5 Student Questions and Answers

5.7 File Timestamps — Access, Modify and Change

Beyond size and permissions, each inode tracks three times. Confusing them is common, so the session isolated each with explicit read and write operations and the stat command, and it corrected an early slide that swapped two ls options.

5.7.1 atime, mtime, ctime Defined

• atime — access time. Updated when the file's contents are viewed or read. Reading with cat, less or opening in an editor advances atime. Even cp reading the source advances source atime.
• mtime — modify time. Updated when the file's contents change. Editing with cat >, appending with echo >>, or overwriting via an editor advances mtime. This is what ls -l shows by default.
• ctime — change time (also called inode change time). Updated when the inode metadata changes — permissions, ownership, link count, or any content change that necessarily changes metadata such as size and mtime. Crucially, ctime is not the creation time; it records the last time the inode structure itself was altered. You cannot set ctime directly; the kernel sets it on any inode write.

A mnemonic used was: a for access, m for content modification, c for inode change. Changing permissions with chmod advances c but not m; changing contents advances both m and c; viewing advances a. The reference texts note that modern mounts may delay atime with relatime for speed, but the logical rule stays.

5.7.2 Viewing Times — stat, ls -lc, ls -lu

Three commands expose the times:

• stat file — full statistics. Example output for 2.txt included: file name, size, blocks, I/O block size $4096$, file type regular file, device id, inode number, links, access field showing the octal permission (e.g., Access: (0644/-rw-r--r--)), owner and group IDs, and three lines for access, modify and change times with second resolution. A sample access line looked like Access: 2024-05-20 12:04:53.123456789. Modify: and Change: lines follow with the same format.
• ls -lc file — long listing that shows change time (ctime) in the date column, i.e., when the inode last changed. The c matches change.
• ls -lu file — long listing that shows access time (atime) in the date column. The u matches use or access.

The session initially swapped these two in one slide and then corrected explicitly: ls -lc shows the inode change time, ls -lu shows the data access time. That correction was flagged as important to remember and is examinable: c = change, u = access.

5.7.3 How Operations Affect Each Stamp

These steps lead to the rule stated as a table:

A name change, a permission change and an ownership change all advance ctime for the objects whose card changed but only content edits advance mtime. Renaming was cited as the classic case where the inode number stays the same while the directory's structure changes.

5.7.4 Worked Examples

5.7.5 Student Questions and Answers

5.8 Links — Hard Links and Symbolic Links

A common team pattern is to give several people the same file by copying it into multiple directories and merging edits later. Links provide a more direct way: they let one set of physical data appear under several names without duplicating the blocks and without merge pain.

5.8.1 The Problem Links Solve

Without links, sharing looks like copy:

cp 2.txt /bits/2_copy.txt
cp 2.txt ~/2_copy.txt

Each copy allocates a new inode and new blocks, and later edits diverge — you must merge. With links, the same data is reachable from several paths and edits converge because they address the same storage.

Visual intuition: draw one data box with inode 3277300, blocks, size 120. Copying draws three boxes with three inode numbers; linking draws one box with three arrows from three names. Watch stat Inode: and Links: to tell which drawing you have.

5.8.2 Hard Links — ln Source Target

A hard link is an additional directory entry that points directly to the physical data.

Creation:

ln 2.txt bits/2_link.txt
ln 2.txt ~/2_home_link.txt

First argument is the source, second is the link name and location. No extra flag is used. You cannot hard-link a directory (the session tried and the kernel refused) — that guard prevents directory loops.

Properties emphasized:

• Can link only to a file, not to a directory.
• Cannot cross file system boundaries — source and link must be on the same file system because inode numbers are only unique within one file system.
• Always refers to the source data, even if the original name is moved or removed — all names are peers, there is no "original" after creation.
• Shares the same inode number as the source. So ls -li 2.txt bits/2_link.txt ~/2_home_link.txt shows identical inode numbers in the first column (e.g., 3277300 three times).
• Increments the link count (second column of ls -l, also "Links:" in stat). After two hard links were added to 2.txt, the count rose from 1 to 3. Deleting one name decremented the count back to 2 while the data remained reachable.
• Type character stays - (the link is not l); it is not a shortcut file, it is another name for the same regular file.

Behaviour on removal. Removing the original name:

rm 2.txt
ls -li bits/2_link.txt
stat bits/2_link.txt

The data does not disappear. ls -li still shows the same inode number 3277300, stat shows Links: 2 (decremented by one) and Blocks: still allocated. The link count tracks how many names point at the data; the file system only frees blocks when the count reaches zero and no process holds the file open. The session used this to teach that rm removes a name, not necessarily the data.

Real-world: hard links let a project keep one large dataset under several project directories without paying storage twice and without divergence risk, as long as all names stay on one file system. Backup tools use hard links for deduplicated snapshots.

5.8.3 Symbolic Links — ln -s Source Target

A symbolic link (also called soft link or symlink) is a tiny file whose content is a path. It is more flexible but more fragile than a hard link.

Creation:

touch 3.txt
ln -s 3.txt bits/3_link.txt

The -s flag selects symbolic mode. Normally the link is given a distinct name (a common convention is 3_link.txt or 3_soft.txt) to avoid confusion with the name already used in the demo. When the exercise used the same name 3.txt inside bits/, the type was still l but the name collision obscured the distinction in the listing — the session recommended a different link name for clarity, e.g., bits/3_soft.txt.

Properties emphasized:

• Can link to files and to directories (hard links cannot link to directories).
• Can cross file system boundaries because it stores a path, not an inode reference.
• Has its own inode number, different from the source. ls -li 3.txt bits/3_link.txt therefore shows two numbers (e.g., 3277310 versus 3277311).
• Its size is small (example: $5$ bytes for a short path 3.txt versus $444$ bytes for the source content in one of the listings) because it stores only the path string. Use ls -l to see that size column.
• Appears in long listings as l and as name -> target with a distinct color. stat on the link without -L shows the link's own metadata; stat -L follows it.
• If the source is moved, removed or replaced, the symbolic link is not updated. It continues to point at the old path, which may become a dangling or broken link. ls -l then shows the l entry in red and cat through it says No such file or directory.

Behaviour on edits. Editing the source and editing through the link differ:

• Editing the source: echo "hello 3.txt" >> 3.txt — reading the link with cat bits/3_link.txt shows the new source content because the link is resolved to the source at read time.
• Editing through the link (e.g., echo "via link" >> bits/3_link.txt) normally follows the link and modifies the source's blocks, so source size grows. Some tools with rm and mv replace the link object itself if used incorrectly; the session's subtle point was that a symbolic link is not the same inode, so changes that overwrite the link file itself are separate from changes that follow the link to the source.

A table or color view with ls -li made the distinction visible: a hard-linked pair shares one inode number; a symbolic pair shows two numbers and the arrow notation.

5.8.4 Comparing Hard Versus Soft Links

The pointer comparison used in the session was that a hard link is like another label on the same identity card, while a symbolic link is a note that says "go look at that other card". The ls colour cue is the same: hard links show no arrow, symlinks show name -> target.

5.8.5 Worked Examples

ln 2.txt bits/2_link.txt
ln 2.txt ~/2_link.txt
ls -li 2.txt bits/2_link.txt ~/2_link.txt

3277300 -rw-rw-r-- 3 alice alice 6 May 20 12:00 2.txt
3277300 -rw-rw-r-- 3 alice alice 6 May 20 12:00 bits/2_link.txt
3277300 -rw-rw-r-- 3 alice alice 6 May 20 12:00 /home/alice/2_link.txt

rm 2.txt
ls -li bits/2_link.txt ~/2_link.txt
# 3277300 -rw-rw-r-- 2 alice alice 24 May 20 12:01 bits/2_link.txt
# 3277300 -rw-rw-r-- 2 alice alice 24 May 20 12:01 /home/alice/2_link.txt
stat bits/2_link.txt
# Inode: 3277300  Links: 2

ln -s 3.txt bits/3_link.txt
ls -li 3.txt bits/3_link.txt
# 3277310 -rw-rw-r-- 1 alice alice 0 May 20 12:02 3.txt
# 3277311 lrwxrwxrwx 1 alice alice 5 May 20 12:02 bits/3_link.txt -> 3.txt

rm 3.txt
cat bits/3_link.txt
# cat: bits/3_link.txt: No such file or directory
ls -l bits/3_link.txt
# lrwxrwxrwx 1 alice alice 5 May 20 12:02 bits/3_link.txt -> 3.txt   (shown in red)

5.8.6 Student Questions and Answers

5.9 Practice Worksheets and Submission

The session closed with structured hands-on work intended to reinforce inodes, permissions, links and timestamps. The task was to capture terminal output into a single text file and submit it through the course portal. Worksheets were designed to be completed over the week; each asks for before and after evidence so gaps are visible.

5.9.1 Worksheet Tasks

Worksheet 1 — Hard link with info.txt.

1. Create info.txt with the content "This is info." — verify with cat info.txt.
2. Record its inode number (ls -i info.txt) and its link count (second column of ls -l info.txt or stat info.txt Links: line). Expect Links: 1 and size equal to the text length plus newline.
3. Create a hard link with ln info.txt info_hard.txt (or ln info.txt bits/info_hard.txt variant) and record the link's inode number (ls -li info.txt info_hard.txt shows the same number twice), file type character (-, not l), content (cat info_hard.txt matches info.txt), and whether editing one name changes what the other sees. Demonstrate with cat >> info.txt adding a line such as added via hard and then cat info_hard.txt — the new line must appear.
4. Note the link count increment before (1) and after creation (2) and after removal with rm info_hard.txt back to 1. stat before and after proves the count and shared inode.

Worksheet 2 — Symbolic link. Repeat a parallel study for a symbolic link:

1. Create the same source info.txt (restore if you removed it) and note its current size.
2. Create a symbolic link with ln -s info.txt info_soft.txt (use a distinct name to avoid collision).
3. Record the link's inode number (ls -li info.txt info_soft.txt shows two different numbers), file type l with info_soft.txt -> info.txt and colour highlight, size difference (link size is length of info.txt path, e.g., 8, versus source size e.g., 14), and content as seen through the link (cat info_soft.txt shows the source text because lookup follows the path). Change content via the source with echo "soft follows" >> info.txt and show whether cat info_soft.txt follows the change — it must.
4. Observe and note the link count behaviour: stat info.txt Links: stays 1 (symbolic links do not increment the source count); stat info_soft.txt shows Links: 1 for the link's own name.

Worksheet 3 — Old and old_soft.

1. Create old.txt and a symbolic link old_soft.txt pointing to it (touch old.txt; ln -s old.txt old_soft.txt).
2. Add content to old.txt with echo "first" > old.txt, then inspect both names (cat old.txt; cat old_soft.txt — same content). Then append via the link target or through the link as specified in the handout (echo "via soft" >> old_soft.txt follows to the source on most writes). After each command cat old.txt and cat old_soft.txt should match while the link exists.
3. Report the content of old.txt and old_soft.txt after each step, plus ls -li old.txt old_soft.txt to show two inodes but converged content, to make clear when the link follows the source and when it holds its own path string.

Ancillary exercises repeated throughout the session included:

• touch 1.txt then ls -l to note default rw-rw-r-- $664$ and which umask produced it.
• chmod 000, 700, 760, 741, 666, 774 variations on the same file with ls -l verification after each, noting which operation was idempotent.
• stat 2.txt series capturing access, modify and change times after cat, chmod and echo >> to tick each clock once, then ls -lc/ls -lu side by side to confirm the three lenses.
• ls -li /dev > output.txt to create a persistent snapshot of the device directory for review of c versus b and small inode numbers.

ls -li info.txt info_hard.txt
# 3277400 -rw-rw-r-- 2 alice alice 14 May 20 12:10 info.txt
# 3277400 -rw-rw-r-- 2 alice alice 14 May 20 12:10 info_hard.txt
stat info.txt
# Inode: 3277400  Links: 2  Access: ... Modify: ... Change: ...
cat info.txt
# This is info.
cat info_hard.txt
# This is info.

5.9.2 What to Capture and Submit

The expectation announced was to copy the command output from all worksheets into one text file. The file should contain:

• The inode (ls -i) and link count (ls -l second column or stat Links:) answers for each source and link before and after each creation and removal.
• The post-chmod listings (ls -l) that show how each octal (000, 700, 760, 741, 666, 774) or symbolic (u+rwx, g+r, o+x, a+rwx) mode changed the ten-character string, with the octal or symbolic input echoed alongside.
• The stat and ls -lc/ls -lu outputs that demonstrate which timestamp moved and which stayed after cat (atime), chmod (ctime), and append (mtime and ctime).
• The cat outputs before and after edits that prove hard-linked names converge and symbolic links either follow or go red and dangling when the source is removed.

Practical capture method used in the session: run command >> submission.txt 2>&1 to append each command's output, or start with ls -li /dev > output.txt for the device snapshot and then cat output.txt >> submission.txt. Verify the final file with cat submission.txt before upload.

That aggregated file was to be uploaded via the assignment link created on the portal for this third session. The session noted that the worksheets can be worked on through the week and submitted by the date announced for this session. Late guidance was to keep the link names distinct (info_hard.txt and info_soft.txt versus reusing info.txt) so the l versus - and shared versus distinct inode remain legible in the captured ls -li.

Exam Guidance Summary

No formal mark distribution or question paper pattern was announced in the captured session. The following examination-relevant guidance emerged from what was practiced and flagged as important:

• Expect to decode and produce ten-character ls -l strings — identify file type from position one (-, d, c, b, l, p, s) and read, write, execute rights for user, group and others. Tasks such as "find the permission of student.doc" and predicting output after chmod fall in this group. Reading method: count to ten, split type | rwx | rwx | rwx, then pick the triplet by owner/group/others.
• Expect to translate between permission triplets and three-digit octal modes in both directions, including specific conversions that were drilled: $000$ (----------), $700$ (rwx------), $760$ (rwxrw----), $741$ (rwxr----x), $666$ (rw-rw-rw-), $664$ (rw-rw-r--) and $774$ (rwxrwxr--). Knowing that $r=4$, $w=2$, $x=1$ and that each digit is $0$-$7$ (computed as $4r+2w+1x$) is essential. The binary table $000\to 0$ through $111\to 7$ is worth memorizing.
• Expect to use both absolute and relative chmod forms: absolute as three octal digits that overwrite all nine bits, relative as $u,g,o,a$ plus $+$ or $-$ plus $r,w,x$ that modifies incrementally (e.g., chmod u+rwx, chmod g+r, chmod o+x, chmod a-rwx, chmod ugo+r). Exam note: the slide explicitly contrasted "has to be in octal decimal numbers only" and rejected binary strings like 110 as invalid mode — write three digits 0–7, not a binary literal.
• Expect questions on ls options: -i for inode number, -l for long listing, -li combined (inode as first column), -lc for change time (ctime), -lu for access time (atime). A corrected pairing to remember is that ls -lc shows inode change time and ls -lu shows access time — the session swapped them early and then corrected to c = change, u = access.
• Expect to differentiate the three timestamps — atime (access, ls -lu, stat Access:), mtime (content change, default ls -l, stat Modify:) and ctime (inode change, ls -lc, stat Change:) — and to say which operation advances which stamp (read with cat advances atime; content edit with echo >> advances mtime and ctime together; permission or ownership change with chmod/chown advances ctime alone; rename with mv inside one file system leaves the file's inode number and mtime unchanged). The file's ctime after a write matches mtime.
• Expect hard and soft link distinctions: hard links share the same inode and increment link count, cannot be made for directories and cannot cross file systems; symbolic links have a different inode, show l and name -> target, size equals path length, can point to directories and across file systems, and become dangling when the source is removed. Commands ln source target versus ln -s source target and removal with rm linkname are testable.
• Expect output capture via redirection > as in ls -li /dev > output.txt versus append >>, and that the resulting output.txt is a regular file - holding the snapshot of a mixed c/b/l device listing.
• Study advice implicit in the session: practice each chmod table row until you can move between binary $rwx$ (e.g., 110), octal $0$-$7$ (e.g., 6), and displayed string (rw-) without a reference; then drill the worksheet trace ls -li → stat → cat → stat around every link and permission step.

Key Industry Applications

• Unified file system interface to hardware. Real-world: listing /dev shows character devices such as terminals (tty, console, pty) and serial or parallel ports (c) and block devices such as hard disks sda, sda1, loop devices (b) through the same directory model as regular files. Systems code, drivers, udev and containers all rely on this uniformity — opening /dev/null or mounting a volume uses the same open path as opening a document, with type and permission bits deciding who may talk to the device.
• Inter-process communication objects. Real-world: named pipes (p, FIFO created with mkfifo) and Unix domain sockets (s in /run, /tmp) appear as file system entries where used, enabling pipelines (producer | consumer), systemd sockets and local service sockets. Pipes and sockets along with shared memory are the canonical IPC techniques named alongside networking courses; choosing a p file versus a s file decides whether the channel is a byte stream or a datagram socket.
• Shortcuts, versions and library aliases. Real-world: symbolic links (l, Windows shortcut analogy) provide version-independent names for libraries (libfoo.so -> libfoo.so.2.1), shared datasets (data -> /mnt/shared/dataset) and deployed binaries (python -> python3). Hard links provide storage-efficient deduplication where one file system hosts the same large object under several project paths, such as rsync --link-dest snapshots where unchanged files are hard-linked across daily snapshots.
• Ownership and collaboration. Real-world: the owner, group and others columns drive team workflows. A project directory can be assigned to a group (chown :team project; chmod 770 project), private files kept at rw------- $600$ or rw-r----- $640$, and shared deliverables opened to rw-rw-r-- $664$ or rw-rw---- $660$. Teams routinely start from 664 for data and 755 (rwxr-xr-x) for directories and scripts, then refine with chmod g+rw or o-r so the semester project passes permissions review on a shared lab machine.
• Auditing with timestamps and inodes. Real-world: stat output, ls -lc and ls -lu support debugging and compliance — forensics compares mtime versus ctime to tell a content edit from a permission change, build systems like make compare mtime to decide what to recompile, and backups decide what changed by comparing ctime versus last backup while avoiding atime churn.
• Redirection and snapshots. Real-world: > output.txt is the primitive behind logging, capturing listings like ls -li /dev into artifacts that can be archived, diffed or submitted through a portal, as required for this session's worksheets. Production scripts chain ls -liR >> log.txt or find . -printf "%i %p\n" >> manifest.txt to create inode-aware manifests that detect duplicates without copying.