wingetCollections
  • Auto
  • Search
  • Awesome Collections
  • Awesome Programs
  • My Favorite Collections
  • My Collections
  • Account / Settings
  • Terms of Service
  • Privacy
  • About

© 2026 winget.ragerworks.com

Loading...
Install ext4-win-driver using Winget - wingetCollections
  1. Go back
  2. Packages
  3. ext4-win-driver
ext4-win-driver logo

ext4-win-driver Antimatter Studios

ext4 filesystem linux mount sd-card usb winfsp
Use this command to install ext4-win-driver:
winget install --id=AntimatterStudios.ext4-win-driver -e

ext4-win-driver is a userspace driver designed to enable Windows systems to mount and interact with ext4-formatted volumes, bridging the gap between Linux filesystems and Windows environments.

Key Features:

  • Auto-Mounting: Automatically mounts ext4-formatted SD cards or USB sticks upon connection, assigning a free drive letter in the active console session.
  • Right-Click Mounting: Offers a "Mount as ext4" context menu option for .img files, facilitating offline inspection of disk images.
  • Command-Line Interface (CLI): Provides tools to browse and interact with ext4 volumes without mounting, supporting operations like info, ls, stat, cat, tree, parts, and audit.
  • Read/Write Support: Defaults to read-write mode but allows switching to read-only for safe inspection via CLI or context menu options.
  • Integration with WinFsp: Bundles the necessary components through a single installer, simplifying setup and ensuring seamless functionality.

Audience & Benefit: Ideal for developers, system administrators, and Linux enthusiasts who require reliable access to ext4-formatted volumes on Windows. It enables efficient file operations, system administration tasks, and troubleshooting without the need for additional software or complex configurations. The tool's robust partition parsing capabilities and support for various disk types make it a versatile solution for handling Linux filesystems within a Windows environment.

README

ext4-win-driver

Overview

This project provides Windows-first userspace tooling for ext4 volumes, built on the fs-ext4 Rust library.

Raspberry Pi SD card auto-mounted as drive F: on Windows 11 ARM64

A Raspberry Pi root-filesystem SD card plugged into a Windows 11 ARM64 host, auto-mounted on F: by the ExtFsWatcher service and browsable in Explorer the moment it appeared.

Scope:

  1. Auto-mount service -- plug an ext4 SD card or USB stick into Windows and the ExtFsWatcher service mounts it on a free drive letter in the active console session. Detach and it unmounts cleanly.
  2. Right-click verb -- "Mount as ext4" on .img files in Explorer for offline disk images.
  3. CLI browser -- open an ext4 image or raw device; list/stat/read files without mounting. Cross-platform (macOS/Linux work too -- handy for testing).
  4. Setup.exe -- bundles WinFsp via a Burn bootstrapper, so end users only run one installer.

The fs-ext4 library lives at vendor/rust-fs-ext4/ (git submodule from christhomas/rust-fs-ext4) and is path-depended; this crate is the distribution unit.

The Windows-driver scaffolding (SCM service, disk-arrival watcher, WinFsp.Launcher integration, partition-table walker, raw-device I/O, installer + CI templates) lives in winfsp-fs-skeleton, vendored at vendor/winfsp-fs-skeleton/. ext4-win-driver is the first consumer of that skeleton -- it was extracted from this project once the auto-mount path was working end-to-end. See The skeleton split below for the boundary.

Status

Shipped in v0.1.0:

  • CLI: info, ls, , , , ,
Versions
0.2.0
0.1.0
Website
github.com
License
Last updated
5/12/2026
Download latest version
stat
cat
tree
parts
audit
  • MBR/GPT partition parsing (5 unit tests)
  • --part N mounts a partition slice via the C ABI's callback mount
  • Win32 raw-device support (\\.\X:, \\.\PhysicalDriveN, \\?\STORAGE#Disk#...) with sector-aligned reads for 4Kn / advanced-format drives
  • WinFsp read-only mount -- verified on Windows 11 ARM64 with both VHD smoke tests and a real Raspberry Pi SD card
  • WinFsp read-write mount (default; --ro for read-only) -- create/pwrite/truncate/rename/unlink/rmdir/mkdir/utimens wired through the C ABI. Streaming positional writes land in fs-ext4 via pwrite, so large-file workloads no longer round-trip the whole file.
  • ExtFsWatcher SCM service -- subscribes to disk-class arrivals (GUID_DEVINTERFACE_DISK), walks the partition table directly, probes each partition for the ext4 superblock magic, and asks WinFsp.Launcher to spawn a per-partition mount in the active console session
  • Right-click .img -> Mount as ext4 verb registered under HKCR\SystemFileAssociations\.img
  • MSI + Burn bundle that auto-installs WinFsp if missing (chained via the official WinFsp redistributable MSI)
  • x64 + arm64 Setup.exe built per release tag by GH Actions (.github/workflows/release.yml) and attached to the release.

    • Not yet shipped:

    • winget submission (manifests staged at winget/v0.2.0/)

    Out of scope (intentionally):

    • Code-signing certificate -- the per-year cost isn't justified for an unsponsored side project. Setup.exe will continue to trip SmartScreen on first download until that changes.

    Install (end users)

    Download ext4-win-driver---Setup.exe (arch is x64 or arm64) from Releases, run it, accept the GPL-3 prompt. The installer:

    • chains the WinFsp MSI if WinFsp isn't already installed,
    • drops ext4.exe and Mount-Ext4.ps1 into C:\Program Files\ext4-win-driver\,
    • registers ExtFsWatcher as an automatic Windows service and starts it,
    • registers the ext4-mount service-class with WinFsp.Launcher,
    • registers the "Mount as ext4" right-click verb on .img files.

    Setup.exe /quiet works for unattended installs. SCCM/Intune deploys should push the bare MSI separately, after pushing WinFsp.

    Usage

    Plug in an ext4 SD card or USB stick: nothing else needed. The service picks it up, finds the ext4 partition(s), and mounts each on a free drive letter (E: upward).

    CLI (works on any host):

    ext4 info                           # volume label, sizes, features
ext4 ls      [path]                 # directory listing
ext4 stat    
ext4 cat     
ext4 tree   
ext4 parts                          # MBR/GPT partition table
ext4 audit                          # link-count + dirent integrity scan
ext4 ls      --part 1 /    # browse partition 1

    Manual WinFsp mount (Windows + mount feature):

    ext4 mount  --drive X:                       # read-write (default)
ext4 mount  --drive X: --ro                  # read-only
ext4 mount  --drive X: --part 1     # mount partition 1

    Then browse X: in Explorer, or Get-ChildItem X:\, etc. Ctrl-C to unmount.

    Toggling read-only / read-write

    The default for every mount path is read-write. Pass --ro per-mount, or use one of the system-wide knobs below:

    • Auto-mount service. The WinFsp.Launcher CommandLine for the ext4-mount service-class lives at HKLM\SOFTWARE\WOW6432Node\WinFsp\Services\ext4-mount\CommandLine (32-bit registry view). Default: mount %2 --drive %1 --part %3. Append --ro there to force every auto-mount read-only.
    • Right-click verb. The shortcut runs Mount-Ext4.ps1 which takes a -ReadOnly switch. Edit HKCR\SystemFileAssociations\.img\shell\MountAsExt4\command to add -ReadOnly to the script invocation if you want the verb itself to default to RO.
    • Per-mount via PowerShell. Run Mount-Ext4.ps1 -ImagePath disk.img -ReadOnly for one-off RO mounts.

    The legacy --rw flag is still accepted (silently) so existing scripts and harness.toml configs that pre-date the flip don't break.

    Watch mode (foreground variant of the service, useful for dev / debugging):

    ext4 watch                                  # foreground; logs each arrival

    The skeleton split

    After v0.1.0 was working end-to-end, the platform plumbing was extracted into its own crate (winfsp-fs-skeleton) so the same scaffolding can host future filesystem drivers (qcow2, ntfs, ...) without copy-paste. The boundary:

    Lives in skeleton (reusable)Lives here (ext4-specific)
    service::run<b> -- SCM dispatcher + WinFsp.Launchersrc/main.rs -- Ext4Backend impl (4 const + 1 fn), CLI dispatch
    watch::run<b> -- foreground variantsrc/cmd.rs -- info/ls/stat/cat/tree/parts/audit subcommands
    partition -- MBR/GPT parsingsrc/mount.rs -- WinFsp FileSystemContext impl, fs-ext4 callbacks
    device -- BlockSource + sector-aligned FileSourcesrc/probe.rs -- is_ext4 magic-byte predicate
    probe -- drive-letter selection, GUID_DEVINTERFACE_DISK, DEV_BROADCAST_DEVICEINTERFACE_W parsing
    templates/installer/ -- WiX MSI + Burn shapesinstaller/ -- ext4-customised copies of the templates
    templates/release.yml -- GH Actions x64 + arm64 build matrix.github/workflows/release.yml
    templates/winget/ -- manifest skeletonwinget/v0.1.0/ -- the actual submission

    The public seam is one trait + four constants:

    use winfsp_fs_skeleton::FsBackend;

struct Ext4Backend;
impl FsBackend for Ext4Backend {
    const FS_NAME: &amp;'static str = "ext4";
    const SERVICE_NAME: &amp;'static str = "ExtFsWatcher";
    const LAUNCHER_SERVICE_CLASS: &amp;'static str = "ext4-mount";
    const FILE_EXTENSION: &amp;'static str = "img";
    fn detect(bytes: &amp;[u8]) -&gt; bool { probe::is_ext4(bytes) }
}

    Cmd::Watch and Cmd::Service in src/main.rs just hand off:

    Cmd::Watch   =&gt; winfsp_fs_skeleton::watch::run::(),
Cmd::Service =&gt; winfsp_fs_skeleton::service::run::(),

    Build

    CLI only (any platform):

    cargo build --release

    WinFsp mount + auto-mount service (Windows only):

    cargo build --release --features mount,service

    The release profile statically links the C runtime via .cargo/config.toml so the binary has no libunwind.dll import -- required for the SCM session-0 launch path where the LocalSystem PATH doesn't reach the LLVM-MinGW runtime dir. panic = "abort" is set in Cargo.toml for the same release profile.

    WinFsp build prerequisites

    • WinFsp 2.1+ installed on the build/run machine (winfsp.dev -> MSI, or winget install WinFsp.WinFsp).
    • A forked winfsp-rs is a git submodule at vendor/winfsp-rs/ on the gnullvm-support branch (path-depended; the upstream PR is pending). The fork also requires:
      • LLVM for libclang.dll (winget install LLVM.LLVM)
      • LLVM-MinGW (winget install MartinStorsjo.LLVM-MinGW.UCRT)
    • LIBCLANG_PATH=C:\Program Files\LLVM\bin so bindgen can find libclang.dll.
    • winfsp-fs-skeleton is a git submodule at vendor/winfsp-fs-skeleton/; pure Rust, no extra toolchain requirements.

    Building the installer

    After cargo build --release --features mount,service finishes:

    installer\build.ps1 -ExePath target\release\ext4.exe -Arch arm64

    Produces dist\ext4-win-driver--arm64.msi and dist\ext4-win-driver--arm64-Setup.exe. The script PE-sniffs -ExePath to catch arch mismatches before WiX does. See installer/README.md for the longer walkthrough (WiX 7 install, WinFsp redist pin, etc).

    Testing

    Scenarios live in test-matrix.json and the per-project adapter config in harness.toml. Both are consumed by the shared fs-test-harness, vendored as a git submodule at vendor/fs-test-harness/.

    After cloning, initialise the submodules:

    git submodule update --init --recursive

    Run the test matrix (Mac -> SSH -> Windows VM -> diag pull):

    bash vendor/fs-test-harness/scripts/run-tests.sh                 # full matrix
bash vendor/fs-test-harness/scripts/run-tests.sh basic-ro-list   # one scenario
bash vendor/fs-test-harness/scripts/run-tests.sh --help          # all flags

    On the very first run, the script prompts for VM details (user, IP, SSH key, workdir, image dir) and writes .test-env; subsequent runs skip straight to ship + run + diag-pull. Use --reset to wipe .test-env and re-prompt (e.g. after VM IP change).

    Diagnostics land under test-diagnostics/run-/. See the harness's docs/triage-protocol.md for how to read a failure, and docs/multi-agent-protocol.md for running multiple agents against the same matrix.

    To update a vendored submodule when its upstream releases:

    git submodule update --remote --merge vendor/fs-test-harness
git add vendor/fs-test-harness &amp;&amp; git commit -m "chore: bump fs-test-harness submodule"

    License

    GPL-3.0 -- inherited from the WinFsp Rust bindings. The CLI alone (without the mount feature) doesn't link winfsp and could be relicensed if split out, but the single-license declaration keeps the distribution unit simple.