Audion Disk Tools

Portable-first Windows disk and file operations toolkit for audit, compare, sync, backup mirror, very broad file-type filtering, powerful archiving, and network/SMB workflows from one GUI/CLI tool.

The project is no longer centered on two fixed project folders. In the GUI you can choose any Source and any Target, work directly with external drives, network paths, and large directories, list source files, synchronize, or build archives without copying terabytes into the project first.

At a glance:

Source / Target — a working route over any folder visible to Windows/Python.
Filter — grouped and individual extension masks for documents, development, media, archives, apps, temporary files, and custom patterns.
Operations — compare, one-way sync, two-way sync, hard mirror, quarantine mirror, Manifest / Diff, and saved profiles.
Archiving — ZIP, 7Z, SFX, TAR, TAR.GZ, TAR.ZSTD, plus optional TAR.LZ4 when lz4.exe is available; encryption where the backend really supports it; SFX auto-extraction; optional post-SFX wrapping for transport-friendly containers.
Data transfer — the leading ROOT mode: folder, share, server and cloud alike. One master, a list of machines, five operations; Robocopy or RClone follows from each pair.
Log surface — live terminal, reports, latest report shortcut, UTF-8/Cyrillic, and ANSI colors.

The project keeps two main user launchers:

launcher_project.cmd — main English launcher
launcher_profiles.cmd — configured sync profiles launcher

It also now includes:

launcher_gui.cmd — NiceGUI/pywebview GUI shell over the existing CLI
launcher_project_ru.cmd — Russian copy of the main launcher
launcher_profiles_ru.cmd — Russian copy of the profiles launcher
template-owned builder_main.cmd
template-owned launcher_tools.cmd

Current launcher behavior:

both main launchers and both profiles launchers support FZF and CMD fallback
the GUI keeps the CLI as the source of truth: commands run through system_core\main.py, with output visible in the right terminal
each saved profile in the GUI has grouped and individual extension checkboxes from its include_presets; selected groups expand into runtime --mask-globs
the GUI workspace buttons Source, Target, and List work with arbitrary external folders directly, so large folders do not need to be copied into input
selected source/target paths are stored in the local config\path_history.json cache with up to 100 entries; the current path can be pinned with Pin and removed from pinned paths with Unpin
the GUI can open the latest human-readable report from the right panel
the GUI can import and export profiles as JSON: config\sync_pairs.json + config\sync_presets.json
the GUI loads template palettes from config\ui_colors.yaml and stores the selected theme in config\gui_settings.yaml; code_dark is the default
the GUI header now includes theme selection, compact RU-friendly labels, and a resizable right terminal panel
the right GUI terminal supports UTF-8/Cyrillic, ANSI colors, live line-by-line output, and long-line wrapping without horizontal scroll
path input can be provided manually or through the Windows folder picker
launcher runs can be overridden with filename and extension masks such as *.docx or *.docx;*.pdf

GUI Shell In Detail

Start the GUI with:

launcher_gui.cmd

The GUI does not replace the CLI; it turns it into a practical file-manager workbench. The left side is for route, mode, and parameters, while the right side keeps status, progress, and live terminal output visible. Action labels stay short; detailed meaning lives in tooltips, README text, and operation descriptions.

Main GUI areas:

Workspace folders — current source/target, Pin/Unpin, folder open buttons, external route selection, and source file listing.
ROOT actions — DATA TRANSFER leads (a list of machines, five operations, the engine follows from each pair), with FOLDER TO FOLDER below it for the auditor's own pair run.
Saved profiles — direct repeatable jobs from config\sync_pairs.json; each profile opens its run form without an extra child menu. copy_by_mask is one-way; *_backup examples are hard Backup mirror profiles.
Archiving — a dedicated workflow for packaging the selected source into the selected target: normal archives, SFX, encryption, and post-SFX wrapping.
DATA TRANSFER — the leading ROOT action: a transfer across a list of machines with a chosen operation, storage, connections and diagnostics.
Manifest / Diff — build a filtered Source -> Target diff from the current Workbench route, then apply it as One-Way or BACKUP-MIRROR; service checksum buttons can still create or verify __CHECKSUMS__.b3 for source/target.
Preparation — compact preview/dry-run, compare-only, and quarantine variants for manual paths, masks, and saved profiles.
Profiles — import/export JSON for sync_pairs.json + sync_presets.json directly from the operation list.
Right panel — current status, progress, live CLI stdout/stderr, shortcuts for logs, reports, latest report, config, and expanded log view.
Header — tool title, compact theme picker, and RU/EN switch. The terminal width is saved locally in the GUI browser profile.

GUI mode meanings:

BACKUP-MIRROR is hard mirror: copy/update, verify, then delete target-only files only if earlier phases succeeded.
One-way copies new and changed files from source to target; target-only files remain.
Two-Way sync exchanges missing or newer files both ways without automatic deletions.
Preparation contains dry-run, compare-only, and quarantine variants for manual operations, copy_by_mask, and every saved backup profile.

Dry-run/preview is still useful for diagnostics and review, but real safety comes from operation policies and phased apply logic.

What the project does

Manifest / Diff

Build a filtered Source -> Target diff from the current Workbench route and apply it as One-Way copy/update or BACKUP-MIRROR. Empty extension selection means all files. The service checksum commands can still create and verify __CHECKSUMS__.b3 for source or target when a standalone integrity manifest is needed.

Compare

Compare source and target and write reports into output\.

One-way sync

Copy only new or changed files from source into target.

Backup mirror

Mirror source into target. Backup mirror is intentionally hard: target-only files are deleted after successful copy/update/verify phases. MIRROR_SAFE is available as an alternate quarantine policy.

Full sync two-way

Run sync2 to propagate missing or newer files in both directions without automatic deletions.

Archiving

Create archives from the selected source into the selected target. The main GUI line exposes ZIP, 7Z, SFX, TAR, TAR.GZ, and TAR.ZSTD when the required backend is available; TAR.LZ4 appears only when lz4.exe is found. ZIP/7Z/SFX support password encryption; 7Z/SFX also support name encryption; unsupported combinations are dimmed in the GUI. Archives can be verified after creation before optional source deletion. SFX can use Windows environment variables for auto-extraction paths and can optionally be wrapped after SFX compression into ZIP/7Z/ZSTD/TAR/GZ containers for easier transport.

DATA TRANSFER

DATA TRANSFER leads the ROOT list. It used to be two sections — Network operations for LAN, SMB and UNC, and RClone operations for rclone remotes. They split one job by tool rather than by task, so choosing a button meant knowing in advance which tool could reach where.

Now you choose the operation — One-way, Mirror, Move, Two-way, Verify — and the destination. The destination can be a list: one master, several machines, one run. The engine follows from each pair and is named on screen: Robocopy for folders and shares, RClone for clouds, two-way sync and hash comparison. The whole fan-out is built before anything starts, so an impossible pair shows up before the first byte moves.

Pack first archives the source and sends the archives instead of loose files — the only thing that helps with many small files over a network: measured at 24 MB/s for one file against 0.46 MB/s for three hundred small ones. Every operation has a dry run. The delete ceiling (--max-delete) is available and never imposed.

Alongside it in the same section: Storage (size, duplicates, checksums, public links), Connections (OAuth for Yandex/Drive/OneDrive/Dropbox/Box/Mega, S3-compatible by key, SFTP, config encryption) and Diagnostics.

GUI shell

launcher_gui.cmd

Main project launcher

launcher_project.cmd

Russian project launcher

launcher_project_ru.cmd

Profiles launcher

launcher_profiles.cmd

Russian profiles launcher

launcher_profiles_ru.cmd

Builder

builder_main.cmd

Tools and release utilities

launcher_tools.cmd

CLI examples

Create a manifest:

runtime\python.exe system_core\main.py manifest --root "D:\Media" --project-root "%CD%"

Verify a manifest:

runtime\python.exe system_core\main.py verify --root "D:\Media"

List configured pairs:

runtime\python.exe system_core\main.py pairs

Compare a saved pair:

runtime\python.exe system_core\main.py compare --pair "docs_backup"

Run a saved backup pair with its configured policy:

runtime\python.exe system_core\main.py backup --pair "docs_backup"

Preview a backup pair:

runtime\python.exe system_core\main.py backup --pair "docs_backup" --dry-run

Run safe mirror manually:

runtime\python.exe system_core\main.py backup --source "D:\Work" --target "X:\Backup" --mode safe

Run hard-delete mirror manually:

runtime\python.exe system_core\main.py backup --source "D:\Work" --target "X:\Backup" --mode strict

Run full sync two-way manually:

runtime\python.exe system_core\main.py sync2 --source "D:\Notes" --target "X:\Notes" --mode safe --dry-run

Exit codes: apply commands return 0 only when errors + conflicts == 0; real sync2 conflicts are not clean success. Preview uses the same conflict/error summary in its JSON output.

Quarantine cleanup is manual and auditable: review _audion_quarantine\... and the generated quarantine report before deleting old quarantine folders.

Current project layout

config\ — presets and saved pair definitions
config\ui_colors.yaml — GUI palettes, CSS tokens, and theme definitions
config\gui_settings.yaml — startup language, selected theme, and GUI-only settings
install\ — builder, install, verify, and release scripts
docs\ — detailed user/project notes, including the GUI guide
system_core\ — Python core and internal helpers
system_core\license\ — template release licensing tools
runtime\ — portable Python runtime
wheelhouse\ — cached wheels for offline reinstall
input\ — user input area
output\ — reports and summaries
logs\ — runtime logs
report\ — GUI run artifacts and machine-readable reports
workspace\ — managed GUI workspace
release\ — release archives
GitHub\ — publication-oriented docs
licenses\ — generated third-party notices for release packaging
._runtime\ — launcher temp files

Cleanup and init folders

install\init_folders.cmd creates the project folders expected by the GUI and CLI: input, output, logs, report, workspace, data, runtime, wheelhouse, release, ._runtime, system_core, install, and licenses.

cleanup_project.cmd is a source-cleanup helper for preparing a clean portable folder. It keeps source files, docs, permanent configs, sync profiles, and licenses, while clearing managed input/output/logs/report/workspace/data, runtime/build payloads, temp folders, and Python caches. It checks Audion Disk Auditor project markers and refuses to clean outside the project root.

Launcher temp scheme

The main launchers now use dedicated fixed temp files under ._runtime\:

EN: project_menu_en*, project_path_mode_en*
RU: project_menu_ru*, project_path_mode_ru*
profiles EN: profiles_menu_en*, profiles_path_mode_en*, profiles_pick_en*
profiles RU: profiles_menu_ru*, profiles_path_mode_ru*, profiles_pick_ru*
builder/tools: template builder_menu*, tools_menu*

The old split *_fzf.cmd launcher generation is being retired in favor of the unified template-style launcher flow.

Validation Snapshot

Confirmed on real folders during the current validation pass:

launcher_project.cmd, launcher_project_ru.cmd, launcher_profiles.cmd, and launcher_profiles_ru.cmd start cleanly in both FZF and CMD fallback
compare, sync, backup, and sync2 were validated on real source and target folders
copy_by_mask with *.docx copied 29 real DOCX files into a real target folder
manifest created a real __CHECKSUMS__.b3 file with 2478 entries
verify checked that manifest successfully with ok: true

Still interactive by nature:

the Windows folder picker flow uses system_core\Pick-Folder.ps1 and requires a real GUI selection

Limitations

The project works with paths that Windows or Python can access as normal directories:

local disks
external disks
UNC network paths
mounted network folders
cloud-synced local folders
mounted remotes such as rclone mount

It does not talk directly to cloud APIs.

Practical recommendation

For day-to-day Backup mirror jobs, keep operation_policy=mirror_hard and mode=safe. Old dry_run_default keys are ignored with a deprecation warning; use explicit operation_policy instead.

Canonical Workbench labels

Workbench uses the same Audion Image Tools public vocabulary in every project. Its buttons always keep the same order and labels: Source, Add file..., Target, Reset, Delete, List.

Reset returns to project input/output and does not delete files; Delete clears the current Source and Target only after confirmation. The exact Russian labels are Источник, Добавить файл..., Назначение, Сбросить, Удалить, Список. The Workbench variants Destination, Clear, Цель, and Очистить are not used.