Links Archives and Disk Usage

What you will be able to do

• Explain the five core decisions involved in links archives and disk usage.
• Choose the narrow Linux command or method that matches a stated operational need.
• Interpret command output as evidence before deciding whether to change system state.
• Apply an observe, act, verify, and recover workflow to a realistic Linux task.

01

Build the Operating Model

Distinguish hard and symbolic links, create inspectable archives, and measure file and filesystem use before storage changes.

Reliable Linux work separates observation, decision, action, and verification. That order keeps a command from becoming a guess and makes each result useful for the next decision.

Begin in a disposable lab or a recoverable environment. Record the active user, working directory, target, and baseline output before any command that can change system state.

02

Hard links

A hard link is another directory entry for the same file data and shares the file's inode. This distinction helps identify the smallest relevant part of the system before a change is attempted.

Create a hard link only within a compatible filesystem and compare inode numbers to verify the relationship. Keep the command, target, and visible result together so another person can reproduce the reasoning.

The safety boundary is clear: hard links normally do not cross filesystems. You should be able to verify this result: two names reference the same inode.

03

Symbolic links

A symbolic link stores a path to another location and remains a distinct filesystem object. This distinction helps identify the smallest relevant part of the system before a change is attempted.

Choose an absolute or deliberate relative target, create the link, and inspect where it resolves. Keep the command, target, and visible result together so another person can reproduce the reasoning.

The safety boundary is clear: the link can break when its target moves. You should be able to verify this result: a separate link points to a target path.

04

Archive creation

The `tar` utility can collect several files and directories into one archive for transport or backup workflows. This distinction helps identify the smallest relevant part of the system before a change is attempted.

Name the archive explicitly, list the intended inputs, and keep the archive outside a directory being collected. Keep the command, target, and visible result together so another person can reproduce the reasoning.

The safety boundary is clear: an archive is not verified until inspected. You should be able to verify this result: one archive contains the selected entries.

05

Archive inspection

Listing an archive shows stored names without extracting them into the current filesystem. This distinction helps identify the smallest relevant part of the system before a change is attempted.

Inspect entry names before extraction and choose a controlled destination for unfamiliar archive contents. Keep the command, target, and visible result together so another person can reproduce the reasoning.

The safety boundary is clear: do not extract unknown paths into valuable data. You should be able to verify this result: stored paths are visible before extraction.

06

Storage measurement

The `du` command summarizes space used by files, while `df` reports available space for mounted filesystems. This distinction helps identify the smallest relevant part of the system before a change is attempted.

Use `du` to find large directory trees and `df` to check the capacity of the containing filesystem. Keep the command, target, and visible result together so another person can reproduce the reasoning.

The safety boundary is clear: allocated use and file size may differ. You should be able to verify this result: object usage and filesystem capacity compared.

07

Apply One Controlled Change

Start from the read-only commands that reveal identity, scope, and current state. Write the expected result before entering a modifying command, including which files, processes, accounts, or connections may be affected.

Make one narrow change and stop. If the output reports an error or an unexpected target, preserve that evidence and return to inspection instead of adding unrelated commands.

Repeat the original observation after the action. A successful command status is useful, but the real completion signal is the intended state plus the absence of an unintended side effect.

08

Complete the Evidence Loop

A good terminal record answers four questions: what was observed, why one action was selected, exactly what changed, and how the result was verified. A screenshot without command context answers fewer questions than saved text output.

Test both the expected success and one safe failure condition. This confirms that the procedure recognizes a wrong path, missing permission, invalid input, stopped service, or unavailable endpoint instead of silently continuing.

Finish by restoring the lab baseline when the task was experimental. For an operational change, record the final state and the reversal step so later work begins from a known boundary.

09

Recap Before Practice and Prove

The first decision concerns hard links. Create a hard link only within a compatible filesystem and compare inode numbers to verify the relationship.

The second decision concerns symbolic links. Choose an absolute or deliberate relative target, create the link, and inspect where it resolves.

The third decision concerns archive creation. Name the archive explicitly, list the intended inputs, and keep the archive outside a directory being collected.

The fourth decision concerns archive inspection. Inspect entry names before extraction and choose a controlled destination for unfamiliar archive contents.

The final decision concerns storage measurement. Use `du` to find large directory trees and `df` to check the capacity of the containing filesystem. Keep the final output as the baseline for the next task.