bobranten/Ext4Fsd: a Windows ext4 driver whose best features are in git, not in the installer

A branch of Ext2Fsd adding checksums, a wider journal, and a newer compiler

The project describes itself as a branch of the Ext2Fsd project by Matt Wu, and the branch has two stated purposes. The first is implementing support for metadata checksums and for the second generation journal, and the README says the current status is that all metadata checksums are implemented and jbd2 has been ported to support 64-bit block numbers, followed by the sentence that the driver is now ready to be tested. That is the whole contribution in one line, and both halves matter for a filesystem created by a current Linux tool. The second purpose is more prosaic and just as useful, which is updating the project so it compiles with Visual Studio 2019 and Visual Studio 2022. The original project predates both compilers, so a codebase that has to be recompiled by anyone not using a supported toolchain is not a codebase anyone can patch. The attribution section records Matt Wu and Ka Ho Ng as previous developers, thanks Olof Lagerkvist, and names the current developer, and the work is dedicated to the author's mother. The original project's own website is still linked, which is worth remembering for the comparison later. Nothing in the README claims conformance testing, and the words ready to be tested are the author's assessment rather than a certification, so the reasonable expectation is that the features work and that the edges have not been shaken out by anyone else yet.

The release is from 2024, the binaries live on a personal page, and they are signed

The distribution arrangement is unusual enough that it is the first thing to understand. There is one release, version 0.71, published on 2024-03-16, and the artefacts are not attached to the repository at all. They are hosted on the maintainer's own web space, with a separate installer for a signed driver on Windows 10 and Windows 11, a directory of signed driver files for manual installation that the README notes also cover ARM and ARM64, and an older unsigned installer for Windows XP through Windows 8. The signing matters more than it sounds. A Windows kernel driver will not load without a valid signature under modern driver policy, so a project that only shipped source would be unusable, and the fact that signed binaries exist at all is what makes this a practical option rather than a curiosity. That advantage ends the moment you want the new features. The README is explicit about the arrangement: most users can continue with the latest release, which contains an installation program and a signed driver, and the list that follows is what has been implemented in the source since then, with the instruction that if you need any of those features you should compile the driver or the application yourself. The procedure it then gives is short. Run the installation program once, then copy your own driver file over the old one in the Windows system drivers directory. Your build is no longer the signed artefact, and the signing you would need for it is your problem, not the project's.

Mounting read-write writes to the superblock, and the 2038 fields

The most technically interesting change in the post-release list is not one of the two headline features, it is a set of new time fields, and it changes what a mount does to the disk. The existing time fields in the superblock and in the inodes use 32-bit values for seconds since 1970, and they will overflow in 2038. The code extends the filesystem with new fields to carry the rest: in the superblock, names ending in an underscore and hi, holding the high 8 bits of the seconds while the existing fields hold the lower 32; in the inodes, names ending in an extra, holding the high 2 bits of the seconds and the nanosecond component encoded as the nanoseconds shifted left by two combined with an epoch value. The fields are then used. Query volume information reads the creation time and its high part. The modification time and its high part in the superblock are updated with the current time at mount time, and the write time and its high part are updated at shutdown. So a read-write mount performs a write to the filesystem before you touch a single file, and the two timestamps reflect the Windows machine rather than the Linux one that last touched the volume. That is normal for a native filesystem, and it is the kind of thing that surprises people who expect a driver to be a reader. It also means two things for an evaluation. A read-write mount of a volume you care about is a modifying operation, so take a copy first. And the extended field names are this project's own addition to the on-disk format, so a volume written by it carries fields that other ext4 tools will not know about, which is a compatibility question the README does not discuss.

Two feature lists decide compatibility: silent read-only, and six refusals

The compatibility contract is written as two explicit lists, and this is the most useful part of the README. The first is the read-only list. If a filesystem carries any of five ext4 features, the driver mounts it read-only automatically, and those five are the bigalloc allocator, quota, project quota, verity and the orphan present flag. Mounting read-only rather than refusing is a good default, and the practical consequence is that a filesystem created with any of those features will quietly give you a read-only drive letter with no obvious error at the point where you discover you cannot save a file. The second list is the refusal list, and it is the one that will cost you an afternoon. If any of six features is present, the driver cannot mount the filesystem at all: extended attributes in inodes, multiple mount protection, inline data, encryption, case folding, and the three-level directory index. Several of these are the kind of feature a current Linux filesystem can be created with rather than something exotic, which is why the check has to be made against the specific volume you want rather than assumed. Encryption is the obvious one for anyone with a laptop disk, and case folding is called out in the README as claimed to be used by SteamOS as a default. Inline data matters on filesystems with many very small files, and the large directory index matters on a directory big enough to need it. The feature that would matter most on a modern root filesystem is multiple mount protection, and the honest way to put it is that you cannot tell from a Windows machine whether a given volume has it, which is the gap the manager application fills.

Ext2Mgr first: the plus sign, the extra filesystem types, and a zero for swap

Because a refusal gives you nothing to work with, the manager application is the tool to reach for before the driver. The README explains that Ext2Mgr gives more detailed information about the type of filesystems on the disk, and that if an on-disk filesystem contains new ext4 features not supported by the Windows driver it will show a plus sign after the filesystem name, with EXT4 plus as the example. It can be run alongside an already installed driver, which means you can inspect a volume before you have decided anything about mounting it. Two changes since the release make it more useful than the version that shipped with 0.71. More filesystems are recognised, so the main window listing disks and partitions now reports the filesystem type for BTRFS, XFS, BSD, LVM and software RAID in addition to the ext family. That is identification only, not support, and it is genuinely useful because it lets you see that a volume is inside a logical volume manager or an array before you try to open it as a plain partition. The second change is smaller and is an honest limitation rather than a feature, since the used size of swap partitions is listed as zero, which is a placeholder rather than a measurement. Put together, the sensible sequence is to run the manager, read the filesystem type, look for a plus sign, and only then decide whether a read-write mount is a reasonable idea. The driver also has a debug build, and the post-release list includes a fix for a crash in it caused by a number of memory pool calls having been replaced with direct calls, an error the README says cannot occur in the release build.

Extending and shrinking extents, and replaying the journal, from Windows

The supported features list describes a driver that does real work rather than a viewer. It handles flexible inode sizes above 128 bytes up to the block size, the hashed directory index, extended file type information in directory entries, files larger than 4 gigabytes, superblock backups in group descriptors, uninitialised background groups, and the first flexible metadata group. It supports symlinks and hardlinks. It supports extents in full, and the parenthetical is the important part, with extending and shrinking, which is a write path capability rather than a read one. It supports the journal, and the caveat there is that only replay for an internal journal is supported, so an external journal device is not covered. It also offers a mount-as-user option to specify the owner and group by user, which is what makes a Windows mounted volume carry plausible Linux ownership rather than everything belonging to one account. Two observations follow from the list. First, a driver that extends and shrinks extents and replays a journal is doing the parts of ext4 where a bug turns into corruption rather than into an error message, and there is no test suite or continuous integration described anywhere in the README, so the assurance available to you is the author's statement that the driver is ready to be tested. Second, the write path is why the read-only fallback list matters so much, since a read-only mount cannot damage the layout no matter how the volume is configured. If you need a volume mounted read-write on Windows as a matter of routine rather than occasionally, the honest question is not whether this driver supports the features but what your recovery path is when it does not, because a filesystem with no journaling driver and no other operating system to repair it with is a different proposition from the same filesystem on a machine that can boot Linux.

A GPLv2 claim in prose, a Visual Studio solution, and one maintainer

Two administrative details are worth recording. The first is the licence. The introduction states that this is free and open-source software and that everyone can modify or distribute it under GNU GPLv2, and that is the only statement of terms in the README. There is no licence file in the top-level file list, which holds a solution file, the driver directory, the service directory, the manager directory, the setup directory, a DIRS file, a readme and a gitignore, so the GPLv2 grant exists as a sentence in a readme rather than as a text you can point a compliance process at. For a driver that people install into a kernel, that is a gap worth closing with the author rather than assuming. The second is the build. The repository contains a Visual Studio solution, which means the toolchain is Windows and Microsoft's, and the README states the project has been updated for Visual Studio 2019 and 2022. So the path to the new features is not portable, it is a Windows workstation with a supported compiler, which for some readers rules out the branch entirely. The maintenance picture is a single named developer, no release since 2024-03-16, and a source tree last pushed on 2026-04-27, so the work is happening in git rather than in a published binary. The README's own framing is the fair summary of that: most people can carry on using the release, and the list of what is new is there for the people who need it and are prepared to build it.

Editorial conclusion

Ext4Fsd is the right tool for reading an ext4 volume from Windows on a machine where installing Linux is not an option, and the honest reason to prefer this branch over the original project is the pair of features it adds, metadata checksums and 64-bit journal block numbers, neither of which is in a published binary. That is also the whole catch, because getting them means compiling the driver with Visual Studio 2019 or 2022 on Windows and replacing the file in the system drivers directory, which puts you outside the signed installer and outside any signing the release had. Two things should be settled before you write anything. Run Ext2Mgr first, because the plus sign it shows after a filesystem name is the only warning you will get before the driver decides a volume is too exotic, and read the two feature lists, since five features silently downgrade a mount to read-only and six make it refuse to mount at all. And take a copy of the data partition before a read-write mount, since the driver updates superblock timestamps at mount and at shutdown, so mounting is itself a write.

Frequently asked questions

Official sources

1. bobranten/Ext4Fsd on GitHub
2. Issues
3. README
4. Releases