Everything you have run so far was harmless: looking, listing, querying. This lesson crosses the line. From here on the commands write to the disk, and some of them delete without asking and with no way of undoing it.

This is not a rhetorical warning. On Linux there is no recycle bin by default: rm unlinks the file and the space becomes available for reuse. Recovering something deleted on a mounted, in-use file system is, in practice, impossible. That is why this lesson devotes a whole section to defensive strategies, and why the VM snapshot matters more today than ever.

In exchange, these are the tools you really work with: creating directory structures, copying while preserving permissions, moving and renaming, synchronising complete trees and packaging software for distribution. By the end you will be able to prepare a package of /opt/tramontana/app ready to send to Luis, confident that it will arrive exactly as it left.

1. touch: creating and touching timestamps
2. mkdir and rmdir: directory structure
3. cp: copying, and the trailing-slash trap
4. mv: moving and renaming
5. rm: the serious conversation
6. Batch renaming with rename
7. rsync: the right way to copy directories
8. tar: packaging
9. Compression: gzip, bzip2, xz and zip
10. Practice: preparing the package for Luis

touch does two different things depending on whether the file exists:

• If it does not exist, it creates it empty.
• If it does exist, it updates its timestamps without touching the contents.

Zero bytes: it exists but it is empty. It accepts several arguments:

The second function, updating timestamps, is the one that gives the command its name and the one that surprises anyone who only knows it as "create an empty file". Picking up the three timestamps from the previous lesson:

Notice what has not changed:

The mtime says January, but the ctime says today. It is exactly what the exercise in lesson 02-03 anticipated: you can forge the mtime, but the ctime gives away that the inode was touched just now.

Legitimate uses of touch in administration:

• Creating a lock file or a marker (/var/run/tramontana.lock).
• Forcing a tool that compares dates to treat a file as modified.
• Setting the date of a file restored from a backup so that it matches the original.
• Creating an empty file before giving it restrictive permissions and only then writing to it, so that it never exists with open permissions.

-c is the defensive option: update if it exists, and if it does not exist do nothing. It avoids creating empty files because of a typo in the name.

Without -p, mkdir does not create nested paths:

-p has a second property, as important as the first: it does not fail if the directory already exists.

That makes mkdir -p idempotent: running it ten times leaves the system in the same state as running it once. It is the property you look for in scripts, where a mkdir failing because the directory already existed would abort execution for no reason. You will pick it up again in Module 4 and with Ansible in Module 7.

-m creates with specific permissions in a single operation:

It is better than creating and then running chmod, because between the two operations there would be a window — brief, but real — in which the directory has more open permissions than it should. On a multi-user system, that window is a security problem. The meaning of the 700 is lesson 02-07.

With brace expansion you can create complete structures in one go:

Those braces are brace expansion, a shell feature explained in lesson 03-02. Use it now; you will understand its mechanics later.

rmdir deletes a directory, but only if it is empty:

That limitation is not a defect: it is a safety net. rmdir cannot delete anything by accident because it only acts on empty directories. When you want to remove a directory with contents you will have to use rm -r, and at that moment you are consciously accepting the risk.

rmdir -p removes the whole branch as long as it keeps being left empty:

It deleted august, then 2026 because it was left empty, and then reports.

The options that matter:

cp overwrites without warning. It is the default behaviour and it has destroyed a lot of work:

bookings.csv no longer contains bookings: it contains houses. There was not a single warning.

Compare with the defensive version:

The difference between -p and -a:

The normal copy has today's date; the copy made with -p keeps the original date. The owner changed in both because operator cannot create files belonging to root (that requires sudo; the details are in lesson 02-07).

Practical rule: to copy a directory tree exactly as it is, cp -a. For everything else, cp -r is enough.

This is the behaviour that generates the most confusion in the whole command. The key: cp behaves differently depending on whether the destination exists and is a directory or not.

In case 2, the file is called backup/houses.txt. So far it is intuitive. The surprise comes with directories:

The same command produces two different results depending on whether backup existed. That is the classic failure: you run a copy script twice and the second time it creates a nested backup/data/.

And now the trailing slash on the source, which changes nothing in cp but changes everything in rsync:

With cp, data and data/ give the same result. In rsync they do not, as you will see in section 7. It is one of the historical inconsistencies of Unix that you have to live with.

A practical defence: when copying directories, run ls -d destination first to find out whether it exists. And in scripts, always use explicit, checked destinations.

mv does both things with the same command, because deep down they are the same operation: changing the directory entry that points to a file.

Like cp, mv overwrites without asking, and with one crucial difference: with cp you lose only the destination; with mv you lose the destination and the source is no longer where it was.

This detail explains a behaviour that is disconcerting when you move large files.

The same inode. Not a single byte has been copied: one directory entry has simply been deleted and another created pointing to the same inode. That is why moving a 40 GB file within the same disk is instantaneous.

Now, between different file systems:

The practical consequences of the right-hand branch:

• It takes time: moving 40 GB from / to a USB disk means reading and writing 40 GB.
• It needs free space at the destination throughout the whole operation.
• If it is interrupted halfway (a power cut, Ctrl+C), the destination is left with a partial file and the source may have been partially deleted if there were several files. mv is not atomic across file systems.
• The ctime changes and the owner may change, because a new file has in fact been created.

How to find out whether two paths are on the same file system:

The same device, /dev/sda2: the move will be instantaneous. If different devices appeared, it would be copy-and-delete.

A rule for moving big things between disks: use rsync and delete afterwards, once you have verified. That way, if something fails, the source is still intact.

rm removes files. On a mounted, in-use file system, it does so irreversibly.

-I is the sweet spot: it stops you to think once, without the fatigue of -i asking four hundred times (which ends up making you answer "yes" automatically, which is worse than not asking).

rm -rf is the combination that deletes a whole tree without a single question and without complaining about anything. It is necessary in scripts and it is responsible for most self-inflicted data disasters.

The paradigmatic case is the empty variable. A script contains:

If for whatever reason DEST and SUBDIR are empty — because a previous cd failed, because a configuration file was not read, because there was a typo in the variable name — the line that gets executed is:

This mistake has happened in real companies and has gone as far as wiping out entire production systems. The best-known public case is that of an installer for a commercial game which, for this very reason, deleted the complete home directory of its users.

Modern versions of rm include --preserve-root, which refuses rm -rf /:

But that protection only covers the exact root. rm -rf /home or rm -rf /opt/tramontana run without objection. And with the slash: rm -rf "$DEST"/ when DEST is empty gives rm -rf /, which is protected; but rm -rf "$DEST"/* with an empty DEST gives rm -rf /*, which is not protected and deletes the entire contents of the root.

1. Look before deleting. The habit you already know, now mandatory:

And with patterns, even more so: run ls with the same pattern, check the list and only then change ls for rm with the up arrow.

2. Use -I out of habit in interactive work.

3. A wastebasket with trash-cli. There is an equivalent of the desktop wastebasket for the terminal:

It is useful on your laptop. On a server it has a serious drawback: the files still take up space in ~/.local/share/Trash, and if you were deleting to free up disk, you have freed nothing. Use it with judgement.

4. Defensive aliases. You can make rm mean rm -I by default through an alias. Aliases are covered in lesson 03-01, and there we will discuss why this particular practice is debatable: you get used to a protection that does not exist on any other server, and the day you work on somebody else's machine you will have a false sense of security.

5. Quotes and --. Always quote your variables and use -- before names that come from outside.

6. What really saves you: backups. None of the measures above protects against a deliberate, well-written deletion. The only thing that protects you is having copies somewhere else, and that is lesson 05-08. And in your lab, the VM snapshot.

One last technical note: rm does not delete the contents, it only unlinks the name. The data stays in the blocks until it is overwritten. That means two opposite things: that a forensic analyst could recover it, and that you, in practice, will not be able to, because the system will keep writing over it while you try. For genuinely secure deletion there is shred, with its own limitations on SSDs and journalled file systems.

Renaming fifty files by hand is not an option. rename (the Perl version, which is the one on Debian and Ubuntu) applies a transformation to many names:

-n (or --nono) is mandatory on the first run: it shows what it would do without doing it. It is the equivalent of "look before acting" for mass renames.

More examples:

The s/pattern/replacement/ syntax is Perl regular expressions, the subject of lesson 03-02. For now the literal pattern and -n to verify are enough.

Watch out for two things: on some distributions (Fedora, RHEL) rename is a completely different program with a different syntax, and rename overwrites without warning if the destination name already exists. Add -v to see what it is really doing.

rsync is designed for synchronising directory trees. Compared with cp -a it has three advantages that make it the default tool as soon as the copy is large or important:

A second run, with no changes:

162 bytes instead of 50 MB. It has compared and found nothing to copy. That is the saving that justifies using rsync for anything that gets repeated.

Essential options:

Here it does, and it is mistake number one with this tool:

A mnemonic: the trailing slash means "the contents of". Without a slash, "the folder itself".

--delete combined with this is dangerous, because it deletes everything at the destination that is not in the source. If you get the level wrong, you empty the destination. Always -n first:

-n has shown you that it was going to delete obsolete.txt. Now you decide with information.

Using rsync for real backups — with rotation, linked incremental copies and remote destinations — is lesson 05-08. Here you use it as the good cp for directories.

tar (tape archive) joins many files into one preserving the structure, the permissions and the dates. On its own it does not compress: that is done by an external compressor it calls.

The three operation modes are mutually exclusive, as you worked out by reading the manual in lesson 02-02:

And the options that accompany them:

Creating:

A breakdown of the command, which is the important part:

• -c create, -z compress with gzip, -v show, -f followed by the name of the resulting file.
• -C /opt/tramontana makes tar position itself there before packaging. Without this, it would package opt/tramontana/app/... with the whole hierarchy inside.
• app is what gets packaged, already relative to -C.

Listing before extracting is mandatory:

Why it is mandatory: to check that the archive has a single root directory. If instead of app/... you saw the files loose at the root of the package, extracting it would scatter dozens of files around your current directory. That is what is known as a tarbomb, and cleaning it up by hand is tedious.

Extracting:

Always extracting with -C into an empty directory avoids the tarbomb problem entirely.

Modern versions of tar detect the compression automatically when extracting, so -z, -j or -J are not needed to decompress. They are needed when creating, because there tar cannot guess what you want.

Excluding what should not travel:

And a note that is worth gold: the historical syntax of tar accepts options without a hyphen (tar czf) because it predates the POSIX hyphen convention. Both work. Use the hyphenated one, which is the one people understand.

The Unix compressors work on a single file and by default replace the original:

data.csv no longer exists: it has become data.csv.gz. To keep the original you have to ask for it with -k:

A comparison over a 100 MB text file, which is where these differences show:

The decision rule:

• You compress many times and decompress few (logs rotated daily): gzip. Speed matters more than size.
• You compress once and decompress many times (a release that will be downloaded a thousand times): xz. The compression time is paid once and you save bandwidth on every download.
• You are passing it to somebody on Windows: zip.

zip is the only one that archives and compresses at the same time, as on Windows:

Its big limitation on Linux: it does not preserve Unix permissions or ownership properly. If you package with zip and unpack, the execution bits can be lost and the script stops working. That is why on Linux you use tar, which does preserve them, and zip only when the recipient uses Windows.

Tools for working with compressed files without decompressing them, very useful with logs:

Luis Ferrer needs an exact copy of version 3.2.1 deployed in production in order to reproduce a bug on his laptop. Marta has approved sending it to him. The package must not include logs or temporary files, and it has to arrive intact.

Step 1: verify what you are going to package.

Step 2: create the working directory. You do not package in plain /tmp: you use somewhere with space and where the file will not vanish on the next reboot.

Step 3: package it, excluding what must not leave.

Step 4: verify the result. Never send a package you have not listed.

48 MB compressed to 19 MB, a single root directory app/, permissions preserved (notice the -rwxr-xr-x on the executable) and not a single .log inside.

Step 5: generate a checksum so that Luis can verify that the file has arrived intact. It is the same mechanism you used when verifying the Ubuntu ISO in lesson 01-04.

When Luis receives it, he runs:

Step 6: a local extraction test. Check that the package opens properly before sending it, not after Luis says it does not work.

diff -rq compares two trees recursively and reports only the differences. No output and exit code 0: they are identical. You will see diff in detail in the next lesson.

Step 7: clean up.

A complete, reproducible, verified procedure. Transferring the file to Luis will be done with scp or rsync over SSH, which is lesson 06-02.

Forgetting -r when copying or deleting directories. cp: -r not specified; omitting directory and rm: cannot remove: Is a directory are the same warning.

The trailing slash. In cp it hardly matters; in rsync it decides whether you copy the folder or its contents. And in cp -r, the result depends on whether the destination already existed.

cp and mv overwrite silently. There is no confirmation by default. -i or -n when the destination may exist.

Copying configuration with cp instead of cp -p. You lose the dates, which are often the only clue as to when something was changed.

Packaging with absolute paths. tar -czf x.tar.gz /opt/tramontana/app stores the hierarchy opt/tramontana/app/ inside. Use -C and relative paths.

Extracting without listing first. tar -tzvf before tar -xzf, always.

zip for Linux files. It loses execution bits and ownership. tar for Linux, zip only for Windows.

Tip: rsync -n and rename -n before the real thing. Simulation mode is free and it shows you exactly what is going to happen.

Tip: name your packages with a version and a date. tramontana-app-3.2.1.tar.gz is informative; backup.tar.gz says nothing in three months' time.

Tip: always send a package together with its sha256sum. It costs one command and it eliminates a whole category of incidents.

Tip: before an rm -r, press Ctrl+A and type ls -la in front. You look, then press the up arrow and change it back to the rm. Ten seconds that have saved a lot of data.

In your home directory on srv-tramontana, with the minimum number of commands:

1. Create the structure work/2026/{07,08,09}/reports and work/2026/{07,08,09}/data.
2. Create a file work/2026/08/reports/summary.txt with a modification date of 1 August 2026 at 09:00.
3. Copy ~/data/bookings.csv to work/2026/08/data/ preserving its timestamps, and verify it.
4. Rename every .txt in work/2026/08/reports/ to .md without making a mistake (use simulation mode).

Luis proposes this procedure for making a daily copy of the application before each deployment:

Find at least five problems and rewrite the procedure correctly.

Marta needs to take the booking data and the list of houses to a meeting. She works on Windows and wants to open the files with Excel. She also asks that the package include a short report of what it contains.

Prepare the complete delivery: write the report, package it in the appropriate format, verify the contents of the package and generate the checksum. Justify your choice of compression format.

Solution 1

A single command. Nested brace expansion generates the six combinations and -p creates all the parents. Without -p it would fail because work and work/2026 do not exist.

touch with -t creates the file and sets the timestamp in a single operation. The format is YYYYMMDDhhmm.ss.

The timestamps match to the nanosecond. Without -p, the copy would have the current date. Notice that the destination ends in /: since the directory exists, the copy is made inside it keeping the name.

The \. escapes the dot so that it means a literal dot and not "any character", and the $ anchors the pattern to the end of the name, so that a file called notes.txt.old would not be affected. Both are regular expressions (lesson 03-02).

Solution 2

The problems with Luis's procedure:

1. Both commands overwrite the previous backup without warning. The names app-backup and app.tar.gz are fixed. Every day the previous day's copy is overwritten, so in reality only one copy exists: yesterday's. If the problem is detected two days later, there is nothing to go back to.

2. Worse still: it is overwritten before knowing whether the deployment goes well. If today's deployment fails and you have already crushed the good copy with a copy of the broken version, you have lost your point of return.

3. cp -r preserves neither permissions nor owners. The executable may lose its execution bit and everything ends up belonging to the user running the command. Restoring that copy would leave the application unable to start. It should be cp -a or, better, rsync -a.

4. tar czf with an absolute path. It stores the hierarchy opt/tramontana/app/ inside the package. On extracting you do not get app/ but three levels of directories, and tar warns with "Removing leading / from member names". -C is missing.

5. Two redundant copies of the same thing are made, one uncompressed (48 MB) and one compressed (19 MB), taking up 67 MB per deployment without either of them contributing anything the other does not have.

6. There is no verification. Nobody checks that the .tar.gz can be opened or that it contains what it should. A copy that has not been verified is not a copy: it is an assumption.

7. There is no space check at all. If /srv fills up halfway through the tar, you are left with a truncated file that looks like a valid copy.

The rewritten procedure:

Corrections applied:

• A name with the date and time: each run creates a different file. Nothing is ever overwritten.
• A single compressed package instead of two copies.
• -C /opt/tramontana app: inside the package there is a single, clean app/.
• tar preserves permissions and owners by design, so -a is not needed.
• || exit 1 at every critical step: if something fails, the script stops instead of carrying on as if nothing had happened. It is the &&/|| of lesson 02-01 applied.
• Verification with tar -tzf before treating the copy as good.
• A checksum to detect later corruption.

What it still lacks and will come in due course: rotation (deleting copies older than N days so that /srv does not grow forever), which is done with find -mtime in lesson 03-03; automation with cron (03-07); and a remote destination, because a copy on the same disk as the original does not protect against a hardware failure (05-08).

How to put it to Luis: his procedure goes through the motions of copying but meets none of the three properties of a useful backup — unique, verifiable and restorable. And the most serious one is the first: by using a fixed name, the good copy is destroyed just before you need it.

Solution 3

Choice of format: zip. Marta works on Windows and is going to open the files with Excel. Although on Linux tar.gz preserves metadata better, here that contributes nothing — these are data files, not executables — and it would mean Marta having to install a tool to open it. Windows opens .zip natively with a double click. Compatibility with the recipient outweighs technical purity.

(That cat > file <<'END' is a here document: it writes the whole block into the file. It is explained in Module 3; here you use it as a tool.)

Details of the procedure that deserve comment:

• cd into the directory and zip * instead of zip -r /tmp/x.zip /tmp/for-marta: this way the package contains the three files at its root, without the tmp/for-marta/ hierarchy inside. It is the equivalent of tar's -C.
• cp -p keeps the original dates of the data, visible in the zip listing. Marta can see that houses.txt is from yesterday and bookings.csv from this morning.
• The README answers in advance the question Marta would have asked over the phone: why the CSV looks wrong in Excel. The semicolon separator is the one bookings.csv uses, and in an Excel with Spanish regional settings it usually works straight away, but it is worth documenting.
• The checksum goes in a separate file, not inside the zip: it has to be verifiable without opening the package.

An important note for the real world: bookings.csv contains guest names, that is, personal data. Sending that file off the server by email or over an unencrypted channel has data protection implications. In a real environment, this delivery should be encrypted and should have the approval of the data protection officer. We will come back to file encryption in lesson 06-05.

You are writing to the disk now, and you are doing it with a safety net.

• touch creates empty files and manipulates timestamps, and its ctime always gives the manipulation away.
• mkdir -p is idempotent and creates complete trees; rmdir is safe by design because it only deletes what is empty.
• cp overwrites silently; -a is the option for faithful copies; and the trap of the trailing slash and the pre-existing destination produces different results from the same command.
• mv is instantaneous within the same file system because it only changes a directory entry, and it is copy-and-delete, slow and non-atomic, when it crosses into another.
• rm is irreversible, rm -rf with an empty variable has wiped out entire systems, and the defences are looking first, -I, quotes and, above all, backups.
• rename -n renames in batches with a prior simulation.
• rsync -av is the right cp for directories: incremental, verifiable, resumable, with --dry-run and with the trailing slash that really does matter.
• tar packages while preserving permissions; you list with -t before extracting and use -C so as not to drag absolute paths along.
• gzip by default, xz to distribute, zip for Windows, and you can justify the choice.
• And you have prepared a complete production package: verified, with a checksum and tested before sending it.

You now know how to move files around. What is missing is what is inside them. In the next lesson, Viewing and Editing Files, you will learn to look at the contents without opening an editor using cat, less, head and tail — including tail -F to follow errors.log live while an incident is happening — and to edit them with nano in depth and with the survival vim you will need the day you enter a server where there is nothing else. You will also establish a convention that the course will use from then on: back up the configuration file before touching it. And you will see how to compare two versions of app.conf with diff to find out exactly what changed, which is the question everybody asks after something stops working.