RepoPilotOpen in app →

Canop/dysk

A linux utility to get information on filesystems, like df but better

Mixed

Single-maintainer risk — review before adopting

weakest axis
Use as dependencyMixed

top contributor handles 94% of recent commits; no tests detected

Fork & modifyHealthy

Has a license, tests, and CI — clean foundation to fork and modify.

Learn fromHealthy

Documented and popular — useful reference codebase to read through.

Deploy as-isHealthy

No critical CVEs, sane security posture — runnable as-is.

  • Last commit 4d ago
  • 5 active contributors
  • MIT licensed
Show all 6 evidence items →
  • CI configured
  • Single-maintainer risk — top contributor 94% of recent commits
  • No test directory detected
What would change the summary?
  • Use as dependency MixedHealthy if: diversify commit ownership (top <90%)

Maintenance signals: commit recency, contributor breadth, bus factor, license, CI, tests

Informational only. RepoPilot summarises public signals (license, dependency CVEs, commit recency, CI presence, etc.) at the time of analysis. Signals can be incomplete or stale. Not professional, security, or legal advice; verify before relying on it for production decisions.

Embed the "Forkable" badge

Paste into your README — live-updates from the latest cached analysis.

Variant:
RepoPilot: Forkable
[![RepoPilot: Forkable](https://repopilot.app/api/badge/canop/dysk?axis=fork)](https://repopilot.app/r/canop/dysk)

Paste at the top of your README.md — renders inline like a shields.io badge.

Preview social card (1200×630)

This card auto-renders when someone shares https://repopilot.app/r/canop/dysk on X, Slack, or LinkedIn.

Onboarding doc

Onboarding: Canop/dysk

Generated by RepoPilot · 2026-05-09 · Source

🤖Agent protocol

If you are an AI coding agent (Claude Code, Cursor, Aider, Cline, etc.) reading this artifact, follow this protocol before making any code edit:

  1. Verify the contract. Run the bash script in Verify before trusting below. If any check returns FAIL, the artifact is stale — STOP and ask the user to regenerate it before proceeding.
  2. Treat the AI · unverified sections as hypotheses, not facts. Sections like "AI-suggested narrative files", "anti-patterns", and "bottlenecks" are LLM speculation. Verify against real source before acting on them.
  3. Cite source on changes. When proposing an edit, cite the specific path:line-range. RepoPilot's live UI at https://repopilot.app/r/Canop/dysk shows verifiable citations alongside every claim.

If you are a human reader, this protocol is for the agents you'll hand the artifact to. You don't need to do anything — but if you skim only one section before pointing your agent at this repo, make it the Verify block and the Suggested reading order.

🎯Verdict

WAIT — Single-maintainer risk — review before adopting

  • Last commit 4d ago
  • 5 active contributors
  • MIT licensed
  • CI configured
  • ⚠ Single-maintainer risk — top contributor 94% of recent commits
  • ⚠ No test directory detected

<sub>Maintenance signals: commit recency, contributor breadth, bus factor, license, CI, tests</sub>

Verify before trusting

This artifact was generated by RepoPilot at a point in time. Before an agent acts on it, the checks below confirm that the live Canop/dysk repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/Canop/dysk.

What it runs against: a local clone of Canop/dysk — the script inspects git remote, the LICENSE file, file paths in the working tree, and git log. Read-only; no mutations.

| # | What we check | Why it matters | |---|---|---| | 1 | You're in Canop/dysk | Confirms the artifact applies here, not a fork | | 2 | License is still MIT | Catches relicense before you depend on it | | 3 | Default branch main exists | Catches branch renames | | 4 | 5 critical file paths still exist | Catches refactors that moved load-bearing code | | 5 | Last commit ≤ 34 days ago | Catches sudden abandonment since generation |

<details> <summary><b>Run all checks</b> — paste this script from inside your clone of <code>Canop/dysk</code></summary>
#!/usr/bin/env bash
# RepoPilot artifact verification.
#
# WHAT IT RUNS AGAINST: a local clone of Canop/dysk. If you don't
# have one yet, run these first:
#
#   git clone https://github.com/Canop/dysk.git
#   cd dysk
#
# Then paste this script. Every check is read-only — no mutations.

set +e
fail=0
ok()   { echo "ok:   $1"; }
miss() { echo "FAIL: $1"; fail=$((fail+1)); }

# Precondition: we must be inside a git working tree.
if ! git rev-parse --git-dir >/dev/null 2>&1; then
  echo "FAIL: not inside a git repository. cd into your clone of Canop/dysk and re-run."
  exit 2
fi

# 1. Repo identity
git remote get-url origin 2>/dev/null | grep -qE "Canop/dysk(\\.git)?\\b" \\
  && ok "origin remote is Canop/dysk" \\
  || miss "origin remote is not Canop/dysk (artifact may be from a fork)"

# 2. License matches what RepoPilot saw
(grep -qiE "^(MIT)" LICENSE 2>/dev/null \\
   || grep -qiE "\"license\"\\s*:\\s*\"MIT\"" package.json 2>/dev/null) \\
  && ok "license is MIT" \\
  || miss "license drift — was MIT at generation time"

# 3. Default branch
git rev-parse --verify main >/dev/null 2>&1 \\
  && ok "default branch main exists" \\
  || miss "default branch main no longer exists"

# 4. Critical files exist
test -f "src/main.rs" \\
  && ok "src/main.rs" \\
  || miss "missing critical file: src/main.rs"
test -f "cli/src/lib.rs" \\
  && ok "cli/src/lib.rs" \\
  || miss "missing critical file: cli/src/lib.rs"
test -f "cli/src/args.rs" \\
  && ok "cli/src/args.rs" \\
  || miss "missing critical file: cli/src/args.rs"
test -f "cli/src/table.rs" \\
  && ok "cli/src/table.rs" \\
  || miss "missing critical file: cli/src/table.rs"
test -f "cli/src/filter.rs" \\
  && ok "cli/src/filter.rs" \\
  || miss "missing critical file: cli/src/filter.rs"

# 5. Repo recency
days_since_last=$(( ( $(date +%s) - $(git log -1 --format=%at 2>/dev/null || echo 0) ) / 86400 ))
if [ "$days_since_last" -le 34 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~4d)"
else
  miss "last commit was $days_since_last days ago — artifact may be stale"
fi

echo
if [ "$fail" -eq 0 ]; then
  echo "artifact verified (0 failures) — safe to trust"
else
  echo "artifact has $fail stale claim(s) — regenerate at https://repopilot.app/r/Canop/dysk"
  exit 1
fi

Each check prints ok: or FAIL:. The script exits non-zero if anything failed, so it composes cleanly into agent loops (./verify.sh || regenerate-and-retry).

</details>

TL;DR

dysk is a Linux/Mac command-line utility that displays mounted filesystems with rich tabular output, replacing the basic df command. It shows filesystem metadata (device, mount point, used/free space, inodes) with customizable columns, filtering, sorting, and output formats (normal table, JSON, CSV). The core data comes from the lfs-core crate dependency. Workspace with two members: root package (src/main.rs entry point) and cli/ subpackage (cli/src/ contains all feature modules). Architecture: args parsing (args.rs) → data collection → rendering pipeline with format-specific modules (normal.rs, json.rs, csv.rs), plus col.rs/cols.rs for column management, filter.rs for filtering, sorting.rs for ordering, and timeout.rs for system calls.

👥Who it's for

Linux/Mac system administrators and DevOps engineers who need detailed filesystem usage information with flexible querying, filtering, and export capabilities beyond what df provides. Rust developers building filesystem analysis tools can use the lfs-core library.

🌱Maturity & risk

Actively maintained and production-ready. Version 3.6.1 with CI/CD via Travis, packaged in Conda and repology. The codebase is organized with a workspace structure (root + cli/), uses Rust 1.75+, and includes build scripts for man pages and shell completions. Single maintainer (Canop) but stable release cadence.

Low risk: minimal dependencies (lfs-core as core provider, clap for CLI, serde for serialization), workspace-based organization is clean, and published to crates.io. Single maintainer could be a concern for critical infrastructure, but the tool's scope is narrow and well-defined. No sign of major breaking changes in recent history (v3.6.x).

Active areas of work

No visible PR/issue data in provided snapshot, but the codebase is at v3.6.1 with recent enough structure to include bacon.toml (test runner config) and modern Cargo patterns. The website/ directory suggests active documentation maintenance. No breaking changes indicated.

🚀Get running

Clone and build: git clone https://github.com/Canop/dysk.git && cd dysk && cargo build --release. Run: ./target/release/dysk. Install system-wide: cargo install --path . from repo root.

Daily commands: Dev: cargo build (or bacon if using bacon.toml watch mode). Release: cargo build --release. Build all targets: ./build-all-targets.sh. The build.rs generates man pages via clap_mangen and shell completions via clap_complete.

🗺️Map of the codebase

  • src/main.rs — Entry point for the dysk CLI; orchestrates argument parsing, filesystem scanning, and output formatting.
  • cli/src/lib.rs — Core CLI library exposing the main command logic; all output modes (table, JSON, CSV) dispatch from here.
  • cli/src/args.rs — Argument parsing and CLI option definitions using clap; defines all user-facing flags and their behavior.
  • cli/src/table.rs — Table rendering logic for the default human-readable output mode; handles column formatting and alignment.
  • cli/src/filter.rs — Filesystem filtering engine; implements the -f flag to match filesystems by name, type, or mount point.
  • cli/src/cols.rs — Column selection and ordering system; enables the -c flag to customize visible columns.
  • build.rs — Build script using clap to generate shell completions and man pages; required for distributable binaries.

🧩Components & responsibilities

  • Argument Parser (args.rs + clap) (clap, regex) — Parses CLI flags (-c, -f, -s, etc.) and validates input; produces Config struct passed to lib.rs
    • Failure mode: Invalid flag syntax or conflicting options; gracefully exits with help text
  • Filesystem Scanner (lib.rs + filter.rs) (libc (statfs), regex for filtering) — Reads /proc/mounts, calls statfs() for each mount, applies user filters, and returns sorted results
    • Failure mode: Permission denied on certain mounts; handled via timeout and partial results
  • Column Selector (cols.rs + col.rs) — undefined

🛠️How to make changes

Add a new filesystem column

  1. Define the column metadata in cli/src/col.rs (name, type, getter function) (cli/src/col.rs)
  2. Register the column in the column list used by cli/src/cols.rs (cli/src/cols.rs)
  3. Add unit conversion logic if needed in cli/src/units.rs (cli/src/units.rs)
  4. Update the default column set in cli/src/args.rs if desired (cli/src/args.rs)
  5. Test via -c flag: dysk -c label+your_new_col (cli/src/lib.rs)

Add a new output format

  1. Create a new module (e.g., cli/src/yaml.rs) implementing the formatter (cli/src/yaml.rs)
  2. Add a new variant to the output format enum in cli/src/args.rs (cli/src/args.rs)
  3. Match on the new format variant in cli/src/lib.rs and call your formatter (cli/src/lib.rs)
  4. Export your module in cli/src/lib.rs (cli/src/lib.rs)

Modify the default table display

  1. Adjust column width, alignment, or color in cli/src/table.rs (cli/src/table.rs)
  2. Update the default column set in cli/src/cols.rs (cli/src/cols.rs)
  3. Test via dysk with no arguments (cli/src/lib.rs)

Enhance filesystem filtering

  1. Add new filter condition types in cli/src/filter.rs (cli/src/filter.rs)
  2. Extend the filter parsing logic to recognize new syntax (cli/src/args.rs)
  3. Apply the filter in the main loop in cli/src/lib.rs (cli/src/lib.rs)

🔧Why these technologies

  • Rust — Type-safe systems programming; efficient filesystem scanning with minimal overhead; cross-platform (Linux/macOS) with consistent binary size.
  • clap — Declarative argument parsing with automatic help and shell completion generation; reduces boilerplate for CLI flags and subcommands.
  • serde (via JSON/CSV modules) — Serialization framework enabling multiple output formats (JSON, CSV) without duplicating data transformation logic.
  • Workspace (root + cli) — Separates binary orchestration from reusable library; allows CLI logic to be used as a dependency in other projects.

⚖️Trade-offs already made

  • Separation of binary (src/main.rs) and library (cli/src/lib.rs)

    • Why: Improves modularity and allows the CLI logic to be reused; makes testing the core logic easier without invoking the binary.
    • Consequence: Slight complexity in argument passing; two Cargo.toml files to maintain.
  • Filter and sort logic in userland rather than kernel/syscall level

    • Why: Simpler implementation; user-friendly syntax and flexibility for custom predicates.
    • Consequence: Cannot avoid scanning all filesystems; no optimization at the OS level; timeout handling required for slow mounts.
  • Column metadata and formatting in a unified column registry

    • Why: Single source of truth for column behavior; enables dynamic column selection via -c flag.
    • Consequence: Adding a new column requires changes in multiple layers (col.rs, cols.rs, units.rs); column definitions are tightly coupled to formatters.

🚫Non-goals (don't propose these)

  • Does not provide real-time filesystem monitoring or change notifications.
  • Does not handle authentication or permission-based filtering (operates within user's existing permissions).
  • Does not write to filesystems or modify mount configurations.
  • Not a replacement for lsblk or parted (focuses on mounted filesystems only, not block device inventory).
  • Not a performance profiler (does not track I/O latency or throughput metrics).

🪤Traps & gotchas

  1. The workspace has two Cargo.toml files: root and cli/ — ensure you modify the correct one for dependencies. 2. Version is hardcoded in Cargo.toml and also pinned in build-dependencies; changing version requires both. 3. The lfs-core crate is external (patching commented out in [patch.crates-io]) — if you need to modify core filesystem logic, you must work in lfs-core repo, not here. 4. build.rs runs at compile time; shell completions and man pages are generated outputs, not source-controlled (may not be in git).

🏗️Architecture

💡Concepts to learn

  • Workspace (Cargo) — dysk uses a Rust workspace to split the library (cli/) from the binary (root); understanding this structure is essential for modifying features correctly
  • Clap derive macros (Rust CLI arg parsing) — All CLI argument parsing in dysk uses clap's derive macro pattern; you'll read and write this pattern in args.rs and any new feature branch
  • Serde serialization framework — JSON and CSV output rely on serde; understanding how filesystem structs are serialized is key to adding new output formats or fields
  • VFS (Virtual File System) abstraction — dysk queries mounted filesystems via VFS abstractions; lfs-core handles this, but dysk's filtering/sorting assumes filesystem metadata model consistency across Linux/Mac
  • Build scripts (build.rs) — dysk generates man pages and shell completions at compile time; understanding build.rs is crucial if you add new CLI options that need documentation auto-generation
  • Inode allocation and usage — dysk displays inode counts and usage; understanding inodes (filesystem metadata storage) helps interpret the 'inodes' column correctly
  • Canop/lfs-core — Core library that dysk depends on; provides filesystem metadata collection logic
  • sharkdp/diskus — Similar Rust CLI tool for disk usage; alternative approach to filesystem introspection
  • bootandy/dust — Rust utility for analyzing directory disk usage interactively; complementary tool that dives into directories where dysk shows filesystem-level info
  • Canop/broot — Another Canop project for tree-based filesystem navigation; shares clap/termimad architecture and could integrate dysk output
  • ogham/exa — Rust replacement for ls with modern features; similar philosophy of improving Unix tools with colored, structured output

🪄PR ideas

To work on one of these in Claude Code or Cursor, paste: Implement the "<title>" PR idea from CLAUDE.md, working through the checklist as the task list.

Add integration tests for filter expressions (cli/src/filter.rs)

The repo has sophisticated filtering capabilities (filters.md documentation exists) but no visible test coverage for the filter module. Given the complexity of filter.rs and col_expr.rs, integration tests would validate edge cases like combined filters, type coercion, and operator precedence. This directly improves reliability for users relying on complex filter chains.

  • [ ] Create tests/integration_filter_tests.rs with test cases for common filter patterns documented in website/src/filters.md
  • [ ] Add tests for col_expr.rs parsing edge cases (operators, column references, type conversions)
  • [ ] Test combined filters (e.g., 'fs=ext4 AND use>50%') to ensure AND/OR logic works correctly
  • [ ] Run tests in CI by adding test command to .travis.yml

Add GitHub Actions workflows to replace Travis CI (.travis.yml → .github/workflows/)

The repo uses .travis.yml but GitHub Actions is now the standard. Current setup lacks granular workflow files for Rust testing across multiple platforms (Linux, macOS) despite the tool supporting both. Setting up Actions would modernize CI, improve build speed, and enable platform-specific testing (relevant since dysk works on both Linux and Mac).

  • [ ] Create .github/workflows/rust-tests.yml with matrix strategy for ubuntu-latest and macos-latest
  • [ ] Include cargo test, cargo clippy, and cargo fmt check steps
  • [ ] Add rustfmt.toml and Cargo.toml validation
  • [ ] Test the MSRV (rust-version = '1.75') explicitly
  • [ ] Update README.md badge from Travis to GitHub Actions

Add unit tests for CSV and JSON output modules (cli/src/csv.rs and cli/src/json.rs)

The CLI supports multiple output formats (normal, csv, json) but csv.rs and json.rs have no visible test coverage. These modules are critical for users consuming dysk output programmatically. Tests would ensure output format stability and catch regressions when schema or field ordering changes.

  • [ ] Create tests/csv_output_tests.rs with test cases for CSV escaping, quoting, and header generation
  • [ ] Create tests/json_output_tests.rs with test cases for field serialization, special characters, and nested structures
  • [ ] Test edge cases: empty filesystems, missing fields, unicode characters in mount paths
  • [ ] Validate output against sample filesystem data to ensure format correctness
  • [ ] Run tests via 'cargo test' in CI pipeline

🌿Good first issues

  • Add unit tests for cli/src/filter.rs: the filtering logic lacks test coverage; write tests that verify filter expressions like 'fs=ext4' and 'free>100G' work correctly.
  • Expand documentation in website/src/filters.md: the current docs don't cover all filter operators; add examples for numeric comparisons (e.g., used<50%, inodes>1M) with expected outputs.
  • Add CSV output options (--csv-delimiter, --csv-quote): cli/src/csv.rs exists but the args.rs doesn't expose granular control over CSV formatting; add clap args to cli/src/args.rs and wire them through.

Top contributors

Click to expand

📝Recent commits

Click to expand
  • b8c61ea — version 3.6.1 (Canop)
  • 145ad76 — update changelog (Canop)
  • 2e5390a — fix workspace configuration (Canop)
  • 93af3b1 — Add --bar-width option to configure progress bar width (PeithonKing)
  • f4d8f26 — clarify that conda package is community maintained (Canop)
  • 7c69a34 — Merge branch 'docs/add-conda-forge-install-instructions' of github.com:matthewfeickert/dysk into matthewfeickert-docs/ad (Canop)
  • 32b4bfa — website prevent cache use in current version display (Canop)
  • 7c3e1b9 — docs: Add conda-forge install instructions (matthewfeickert)
  • 785b948 — website: highlight viewed section in TOC (Canop)
  • 6eaac2d — version 3.6.0 (Canop)

🔒Security observations

The dysk codebase demonstrates a generally secure posture with no critical vulnerabilities detected. As a Rust-based CLI utility for filesystem information gathering, it has inherent security benefits from Rust's memory safety guarantees. Minor recommendations include: (1) establishing a regular dependency audit workflow using 'cargo audit', (2) updating the CI/CD pipeline from the deprecated Travis CI, (3) reviewing the build.rs script for security best practices, and (4) considering automated security scanning in the CI/CD pipeline. The project appropriately uses MIT licensing and maintains clean separation between the CLI and core library. No hardcoded credentials, injection vulnerabilities, or exposed secrets were identified in the provided file structure.

  • Low · Outdated Rust Edition — Cargo.toml. The project specifies rust-version = "1.75" which is relatively recent but may miss important security patches from newer Rust compiler versions. Keeping the Rust toolchain current ensures access to latest security improvements and compiler-level protections. Fix: Consider specifying a more recent MSRV (Minimum Supported Rust Version) or regularly updating the toolchain. Review Rust security advisories at https://rustsec.org/ regularly.
  • Low · Dependency Version Constraints — Cargo.toml build-dependencies section. Several dependencies use loose version constraints (e.g., clap = 4.4, toml = 0.7) without patch-level pinning. While not critical for a CLI tool, this could theoretically introduce unexpected changes across builds. Fix: Consider using more specific version constraints (e.g., clap = "=4.4.x") or regularly audit dependency updates with 'cargo audit' and 'cargo outdated'.
  • Low · Build Script Present — build.rs. The codebase includes a build.rs script which has elevated privileges during compilation. While necessary for this project, build scripts should be carefully reviewed for security issues. Fix: Ensure build.rs only performs necessary build-time operations and doesn't execute untrusted code or have overly broad file system access. Regularly audit this file for security issues.
  • Low · Travis CI Configuration — .travis.yml. The project uses .travis.yml for CI/CD, which is deprecated. Travis CI is no longer freely available for open-source projects, and this configuration may be outdated or non-functional. Fix: Migrate to a maintained CI/CD platform such as GitHub Actions, GitLab CI, or similar. Ensure CI pipeline includes 'cargo audit' for security vulnerability scanning.

LLM-derived; treat as a starting point, not a security audit.


Generated by RepoPilot. Verdict based on maintenance signals — see the live page for receipts. Re-run on a new commit to refresh.

Mixed signals · Canop/dysk — RepoPilot