Skip to content

Deleting

Scope: what d actually does, the confirmation dialog and its defaults, what deletion is underneath (unlink — no trash, no undo), the two ways a deletion can free less than the screen promised, and the working habits this guide uses. Everything in this chapter was done on a throwaway copy of the lab. The original was never touched.

Practise on a copy

Deleting is the one chapter where reading is not enough and doing is not safe — on a real tree. So build the expendable one:

$ sh build-tree.sh homedir-del
built /path/to/homedir-del
$ ncdu homedir-del

Same tree, same sizes, nothing in it that anyone wants. Every capture below comes from inside homedir-del/.

The dialog

Select an item and press d. For a file:

┌───Confirm delete─────────────────────────────────┐
│ Are you sure you want to delete "forgotten.zip"? │
│                                                  │
│              yes      no     don't ask me again  │
└──────────────────────────────────────────────────┘

Three things about this dialog, all verified, all worth knowing before your hand is on the key:

  • The default is "no". The focus starts on no, so the absent-minded Enter deletes nothing. Whoever designed this assumed your keypress might be a mistake. (Verified: Enter alone left the file standing.)
  • Confirming takes a deliberate move: ← to yes, then Enter. forgotten.zip vanished from the listing, from the directory on disk, and 5 MiB came off the totals, immediately.
  • "don't ask me again" is the third option, and it means the rest of the session: choose it once and every later d deletes instantly, no dialog. It is there for people clearing fifty cache files in a row. It is also how a distracted minute empties the wrong folder. This guide never uses it, and recommends you treat its existence as a warning label. (2.x goes further and offers --no-confirm-delete on the command line — the same silence, from the first file. Named here so you recognise it; not used anywhere in this guide.)

For a directory, the dialog says what it means, in full:

│ Are you sure you want to delete "Downloads"    │
│                 and all of its contents?       │

One confirmation covers the whole subtree. There is no per-file review inside it, no list of what is about to go, no second chance after the first. A directory delete is recursive, immediate and total. In the captures this dialog was cancelled — the wording is the lesson — but it runs through the same ←, Enter as the file, and on the copy it takes the whole directory with it when confirmed.

What deletion is

Underneath the dialog, ncdu does what rm does: it unlinks the name.

  • The space is freed when the name was the file's last (hard links are below) — and not before. There is no trash can, no undo, no recovery feature in ncdu. A confirmed deletion is as final as your backups are old.
  • It happens on the live tree, at the paths the scan recorded. If the tree has changed since the scan — you renamed the directory in another terminal — chapter 2's r is the honest refresh before you act on old numbers.
  • It only happens in a live scan. In read-only mode (-r) and when browsing an imported export (chapter 6), d answers "Deletion feature disabled." — ncdu will not delete from a picture of a disk, and neither should you.

When deleting frees less than promised

Twice in this guide, a successful deletion frees nothing like the number on screen.

Hard links. Chapter 3's photograph has two names. Deleting one name, verified on the copy — homedir-del/Pictures/holiday before: both img-002 rows at 3.0 MiB with H flags; delete img-002-copy.jpg, confirm — and the directory total is unchanged, 5.0 MiB:

--- /home/.../homedir-del/Pictures -------------------
    5.0 MiB [##############] /holiday
  768.0 KiB [##            ] /screenshots

You removed a name. The data stays, under the surviving name, until that goes too. The browser even keeps showing the stale H on the survivor until you press r — the scan's memory, not the disk's present. When a cleanup "doesn't work," count the names before blaming the tool.

Files still open. A file deleted while a program holds it open loses its name but keeps its blocks until the program closes it — disk full, file "deleted," space unmoved. That one belongs to the running system rather than the browser, and chapter 9 gives it its full treatment.

Working habits

The guide's rules, in the order they bite:

  1. Look with -r, delete without it. Browsing a strange disk read-only costs nothing and makes d a message instead of an accident.
  2. Read the path line before the dialog. The header of the screen names the directory you are standing in. Most deletion disasters are one level up from where the deleter thought they were.
  3. Delete files before directories. A file's dialog names one thing. A directory's dialog names a tree and asks once.
  4. Confirm the space came back. Footer totals update at once; if they did not move, one of the two traps above is the reason — or the scan is stale (r).
  5. Never delete from an old session on a busy disk. Quit, rescan, then delete. The scan is cheap; the alternative is acting on a photograph.

Check: on your own copy, delete Downloads/forgotten.zip (↓ into Downloads, ↓ past the installers, d, ←, Enter) and watch three things agree: the listing loses the file, the footer loses 5.0 MiB, and ls homedir-del/ Downloads outside ncdu has no forgotten.zip. Then rebuild the copy (sh build-tree.sh homedir-del) and the specimen is back — the only deletion in this guide that can be undone, because the tree can.