diff --git a/README.md b/README.md
index 5c1bf70c..cc306bc4 100644
--- a/README.md
+++ b/README.md
@@ -705,7 +705,7 @@ PC Engine CD, CD32, GameCube, Wii, CD-i, and 3DO.
| SGI-DkLabel | Yes | Yes; also writes whole labels from scratch | The pre-IRIX SGI disk label, on IRIS 2000 / 3000 series disks. One `struct disk_label` at block 0: drive geometry, the alternate-block region, and 8 `{base, size}` slots with no type field — roles come from `d_bootfs` / `d_swapfs` / `d_rootfs`, and the whole-disk wrapper slots are excluded from the list. Big-endian, packed for the 68020's 2-byte alignment, and **auto-detects the byte-swapped images** period SGI disk controllers produce. The detected orientation is reported by `inspect` / `ls` and on the GUI's Inspect tab, which also offers a *Swap Word Order...* button; `rb-cli swab16` is the scriptable equivalent. Surfaces its slots to the SGI EFS v1 driver (browse / inspect / extract, and editing the volumes). The eight `{d_base, d_size}` slots are editable — resize / move / add / delete, plus moving `d_bootfs` — with edits written back in the image's own word order and partial slot overlap refused (whole-disk wrapper slots are allowed, since containment is how the label spells "the whole drive"). There is no per-slot type field, so `set-type` is refused with that reason. `rb-cli new hd sgi-dklabel` writes a fresh label with the slots you size and give a role (`root` / `swap` / `boot` / `slice`), cylinder-aligned from `--heads` / `--sectors`, plus the whole-disk wrapper slot every label of the era carries; on the reference geometry (987c/7h/17s) the slots land on the same blocks a real IRIS 3130 uses. Fill them with `rb-cli new volume efs-v1` and `--fill N=PATH`, then `rb-cli swab16` if the target machine wants the controller's reversed-word order. **Full-disk backup works through the single-file-CHD layout**: the label and boot area ahead of the first slot ride verbatim, each slot lands at its declared offset, and an as-is restore is a byte copy — the word order is preserved because those bytes are never interpreted. A resize on restore rewrites the eight slots in the label's own word order. A resize at backup or export time runs the same rewrite before staging; the per-partition layouts (zstd / gzip / raw / VHD) are refused, since restoring one would have to rewrite the label. |
| AHDI | Yes | No (browse); writes whole tables from scratch | Atari ST / TT / Falcon hard disks. Four primary entries at 0x1C6 plus XGM extended chains, big-endian, no magic number — detection keys off the 0x1234 word-sum and plausible geometry. `rb-cli new hd atari` writes a fresh root sector with the tags you name (GEM / BGM / RAW); a GEM partition over 16 MiB is promoted to BGM, which is what TOS needs. Creating an XGM chain, and grafting in a bootable bootstrap, are future work.. **Full-disk backup works through the single-file-CHD layout**: the root sector rides verbatim ahead of the first partition, an as-is restore is a byte copy, and a resize on restore, at backup time or on export rewrites the entries and the 0x1234 word-sum in place. A per-partition backup previously *succeeded* and then failed at restore with "no MBR data available"; it is refused up front now. A disk with an **XGM extended chain** is imaged as one body instead of per-partition — MBR gets away with that shape only because `build_ebr_chain` rebuilds its EBRs on restore, and nothing rebuilds an XGM chain |
| Sun | Yes | No (browse); writes whole labels from scratch | Sun disk label / SMI VTOC (SPARC Solaris / SunOS). 8 big-endian slices (magic `0xDABE`), geometry-derived offsets; the whole-disk "backup" slice is excluded from the list. **SunOS 4.x wrote no VTOC at all** — `sanity`, `version` and `nparts` are zero, so every tag reads 0 and the tag-5 test can't find that alias; there it is identified by geometry instead (a slice from cylinder 0 spanning the label's whole data area), and the slices are shown as `untagged` rather than claiming an `unassigned` tag we never read. Surfaces the UFS slices to the existing big-endian-SPARC UFS reader (browse / inspect / extract). `rb-cli new hd sun` writes a fresh label with the slice tags you name (`root`, `usr`, `swap`, … or a bare tag number), cylinder-aligned from `--heads` / `--sectors`, with slice 2 reserved for the whole-disk alias. Parser and writer both cross-validated against `fdisk` / `sfdisk`; editing an existing label is future work. **Full-disk backup works through the single-file-CHD layout**: the head region — here nothing, because a SunOS root slice starts at cylinder 0 and carries the label in its own first sector — plus every slice at its declared offset, restored as-is by a byte copy, or with the slices rewritten on cylinder boundaries and the checksum restamped when a size changes on restore. The per-partition layouts (zstd / gzip / raw / VHD) are refused with that reason, since restoring one would have to rewrite the label. The same rewrite runs before staging when a size changes at backup or export time. |
-| NeXT | Yes | Yes | NeXT disk label (NeXTSTEP / OPENSTEP, black m68k hardware **and** NeXTSTEP/Intel). Up to 8 partitions, big-endian on both architectures, written as four checksummed copies at 512-byte blocks 0/15/30/45 — all four share one checksum, because it is computed with `dl_label_blkno` read as zero. Partition offsets are counted in the label's own `d_secsize` (1024 bytes on every disk we have) and measured from the end of a front porch, so `PartitionInfo` carries an explicit byte offset for them. Probed ahead of MBR because a NeXTSTEP/Intel disk also carries a valid `0xAA55` boot sector with an empty partition table. Surfaces its partitions to the existing big-endian UFS reader (browse / inspect / extract / edit). `rb-cli new hd next` writes a fresh `dlV3` label with the partitions you name (`4.3BSD`, `swap`, or any 8-byte type string), a 160-sector front porch, and the entry's optional NAME field as the partition's `p_mountpt`; `--heads` / `--sectors` set the recorded geometry and are counted in the label's own 1024-byte sectors. Fill it with `rb-cli new volume ufs-43bsd`, which writes the pre-4.4BSD UFS1 NeXTSTEP actually reads. **`rb-cli optical new next-ufs`** builds a NeXTSTEP CD-ROM image the same way — NeXT CDs are not ISO 9660 but this label in **2048-byte** sectors (32 x 64, an 80-sector porch) around one `4.3BSD` UFS with 2 KiB fragments, and for a disc the size of NeXT's own `NeXTTIME` CD every superblock word and the label's slot 0 come out identical to it. `--from-dir` fills it in one step; `--expand-archives` unpacks tarballs (pre-POSIX tars included) and `--expand-gunzip` only strips the gzip layer, leaving `.pkg` bundles and their `.tar.Z` for NeXT's Installer. Data discs only: no boot blocks. The 8 slots are editable — resize / move / add / delete, `set-type` on the `p_type` name, and `set-bootable` moving `d_rootpartition` — with every edit converted out of 512-byte LBAs into porch-relative label sectors, overlap refused, and **only the copies the disk actually has** rewritten, so a NeXTSTEP/Intel disk keeps the PC boot sector that stands where its block-0 copy would be. **Full-disk backup works through the single-file-CHD layout**: the front porch — label copies, boot blocks and all — is copied verbatim, each partition lands at its declared offset, and an as-is restore is a byte copy; a resize on restore rewrites all four label copies. The per-partition layouts (zstd / gzip / raw / VHD) are refused with that reason, since restoring one would have to rewrite the label. The same rewrite runs before staging when a size changes at backup or export time. |
+| NeXT | Yes | Yes | NeXT disk label (NeXTSTEP / OPENSTEP, black m68k hardware **and** NeXTSTEP/Intel). Up to 8 partitions, big-endian on both architectures, written as four checksummed copies at 512-byte blocks 0/15/30/45 — all four share one checksum, because it is computed with `dl_label_blkno` read as zero. Partition offsets are counted in the label's own `d_secsize` (1024 bytes on every disk we have) and measured from the end of a front porch, so `PartitionInfo` carries an explicit byte offset for them. Probed ahead of MBR because a NeXTSTEP/Intel disk also carries a valid `0xAA55` boot sector with an empty partition table. It is probed ahead of a Sun label too: CDs that also boot on SPARC (the NeXTSTEP 3.3 RISC disc and the OPENSTEP 4.2 Install CD) keep one at block 0 and their NeXT copies at blocks 16 / 30 / 48 instead, which is where a rewrite updates them. Surfaces its partitions to the existing big-endian UFS reader (browse / inspect / extract / edit). `rb-cli new hd next` writes a fresh `dlV3` label with the partitions you name (`4.3BSD`, `swap`, or any 8-byte type string), a 160-sector front porch, and the entry's optional NAME field as the partition's `p_mountpt`; `--heads` / `--sectors` set the recorded geometry and are counted in the label's own 1024-byte sectors. Fill it with `rb-cli new volume ufs-43bsd`, which writes the pre-4.4BSD UFS1 NeXTSTEP actually reads. **`rb-cli optical new next-ufs`** builds a NeXTSTEP CD-ROM image the same way — NeXT CDs are not ISO 9660 but this label in **2048-byte** sectors (32 x 64, an 80-sector porch) around one `4.3BSD` UFS with 2 KiB fragments, and for a disc the size of NeXT's own `NeXTTIME` CD every superblock word and the label's slot 0 come out identical to it. `--from-dir` fills it in one step; `--expand-archives` unpacks tarballs (pre-POSIX tars included) and `--expand-gunzip` only strips the gzip layer, leaving `.pkg` bundles and their `.tar.Z` for NeXT's Installer. Data discs only: no boot blocks. The 8 slots are editable — resize / move / add / delete, `set-type` on the `p_type` name, and `set-bootable` moving `d_rootpartition` — with every edit converted out of 512-byte LBAs into porch-relative label sectors, overlap refused, and **only the copies the disk actually has** rewritten, so a NeXTSTEP/Intel disk keeps the PC boot sector that stands where its block-0 copy would be. **Full-disk backup works through the single-file-CHD layout**: the front porch — label copies, boot blocks and all — is copied verbatim, each partition lands at its declared offset, and an as-is restore is a byte copy; a resize on restore rewrites all four label copies. The per-partition layouts (zstd / gzip / raw / VHD) are refused with that reason, since restoring one would have to rewrite the label. The same rewrite runs before staging when a size changes at backup or export time. |
| Solaris-x86 | Yes | Yes | Solaris x86 nests a 16-slice VTOC in **sector 1 of an MBR partition** (type `0x82` on Solaris 2.x-9, `0xBF` on 10+) rather than replacing the MBR the way SPARC's Sun label does. Little-endian, slice offsets relative to the Solaris partition. Type `0x82` is shared with Linux swap, so detection requires the `0x600DDEEE` sanity word, `v_version == 1`, and slices that fit inside the partition. Surfaces the UFS slices to the existing reader; the disk's other MBR primaries and EBR logicals list after them, since a Solaris disk is still an MBR disk. `rb-cli new hd solaris-x86` writes both halves at once: an MBR with one bootable `0x82` entry starting at cylinder 1, and a full `struct dk_label` in its second sector — VTOC, geometry tail, `0xDABE` magic and the XOR checksum Solaris validates. Slices are cylinder-aligned; slice 2 is the whole-partition backup alias, slice 8 the boot cylinder and slice 9 the two alternates cylinders, so user slices start at the disk's fourth cylinder. The 16 slices are editable — resize / move / add / delete, and `set-type` on the VTOC tag by name or number — with absolute LBAs translated into partition-relative sectors, slices bounded by the label's own `dkl_ncyl` data area, partial overlap refused (the backup alias containing everything is not), and the checksum re-stamped so Solaris still accepts the label. `set-bootable` is refused with the reason: the boot bit is on the MBR entry hosting the label, not on the slices inside it. Backup treats the disk as the MBR it is (the Solaris partition rides as one body) and records the VTOC in `solaris_x86.json`. |
| X68k | Yes | No (browse); writes whole tables from scratch | Sharp X68000 SASI/SCSI hard disks — Human68k's native scheme. 16-byte header plus 8 entries at byte 2048, big-endian, no magic number. Both geometries are auto-detected: SCSI (`X68SCSI1`, table at 0x800, 1024-byte sectors) and SASI (table at 0x400, 256-byte sectors), including custom-IPL game disks. `rb-cli new hd x68k` synthesizes a bootable disk with the Sharp IPL signature and a Human68k FAT volume. |
| DSD | Yes | — (fixed floppy geometry) | Double-sided Acorn DFS (`.dsd`). Not a table on the disk: the two sides are stored track-interleaved, so the reader de-interleaves them and this scheme presents them as **two** Acorn DFS partitions — side 0 at byte 0, side 1 at half the image. Edits to either side re-interleave on save. |
diff --git a/docs/cli-html-help/index.html b/docs/cli-html-help/index.html
index f0801350..5f76f6d1 100644
--- a/docs/cli-html-help/index.html
+++ b/docs/cli-html-help/index.html
@@ -78,7 +78,7 @@
Verbs
tarArchive a filesystem (or a subtree) to a single `.tar.gz` / `.tar.zst` / `.tar`. Preserves exact case-sensitive names and real symlinks, so extracting on a case-insensitive host won't clobber files that differ only in case
terminalOpen an interactive rb-cli shell (rustyline-based REPL)
tuiLaunch the full-screen terminal UI (preview): a menu-driven ratatui app that runs anywhere rusty-backup does, including serial consoles and vintage terminals. Needs an interactive terminal
-
untarImport a `.tar.gz` / `.tar.zst` / `.tar` archive's contents INTO a filesystem in an image (the inverse of `tar`). Recreates the tree, streams files in, and recreates symlinks where the target FS supports them
+
untarImport a `.tar.gz` / `.tar.bz2` / `.tar.zst` / `.tar` archive's contents INTO a filesystem in an image (the inverse of `tar`). Recreates the tree, streams files in, and recreates symlinks where the target FS supports them
updateCheck for a newer release and (when built with `--features tui-update`) self-update. Without that feature it reports that updates weren't compiled in and prints the releases URL, exiting non-zero. Pass `--apply` to download and replace this binary in place
xattrRead or edit a file's extended attributes (`list` / `set` / `rm`) — the scriptable form of the GUI and TUI File Info panel. SquashFS today; other xattr-bearing filesystems as their write side lands
Populate the disc from this host directory after formatting it. The directory's *contents* land at the volume root
--expand-archives
-
With `--from-dir`: unpack tarballs (`.tar`, `.tar.gz`, `.tgz`, pre-POSIX tars included) into a directory named after each, instead of copying them
+
With `--from-dir`: unpack tarballs (`.tar`, `.tar.gz`, `.tgz`, `.tar.bz2`, pre-POSIX tars included) into a directory named after each, instead of copying them
--expand-gunzip
With `--from-dir`: strip one gzip layer only (`x.tar.gz` -> `x.tar`, `f.gz` -> `f`). With `--expand-archives` too, tarballs unpack fully and this takes the other `.gz` files
Import a `.tar.gz` / `.tar.zst` / `.tar` archive's contents INTO a filesystem in an image (the inverse of `tar`). Recreates the tree, streams files in, and recreates symlinks where the target FS supports them
+
Import a `.tar.gz` / `.tar.bz2` / `.tar.zst` / `.tar` archive's contents INTO a filesystem in an image (the inverse of `tar`). Recreates the tree, streams files in, and recreates symlinks where the target FS supports them
Usage
Usage: untar [OPTIONS] <IMAGE> <ARCHIVE> [DEST]
Arguments
@@ -15,7 +15,7 @@
Arguments
<IMAGE>
Image reference (`path` or `path@N` for the 1-based partition index)
<ARCHIVE>
-
Host archive to import (`.tar.gz` / `.tar.zst` / `.tar`; the compression is detected from the file's contents, not its name)
+
Host archive to import (`.tar.gz` / `.tar.bz2` / `.tar.zst` / `.tar`; the compression is detected from the file's contents, not its name)
<DEST>
Destination directory inside the filesystem. Defaults to the root