ReactOS can now install itself to an NTFS partition, format that partition and boot from it, clearing a filesystem barrier that had kept the open-source Windows-compatible operating system tied mainly to FAT32 installations.
The milestone arrived in current development builds in October, not in a new stable release. ReactOS 0.4.16, released on August 29, remains the latest official version, and the project still labels the operating system alpha-quality software that can corrupt data. The new NTFS path is therefore something to test in a virtual machine, not a reason to replace Windows on a working PC.
What ReactOS added
NTFS support did not arrive as one feature. ReactOS gained read-only access in 2016, while its FreeLoader bootloader learned to read and start an installation from NTFS in 2022. Those pieces still did not give the operating system a sufficiently complete filesystem driver to install and run on the partition it was reading.
The latest work closes that gap. According to the ReactOS project and coverage of its announcement, Setup can create a Windows-compatible NTFS volume, copy the operating system to it and continue using the project’s own NTFS driver after boot. Users no longer need a separate FAT32 system volume merely to try a normal installation.
That matters because NTFS is part of the environment ReactOS is trying to reproduce. The project implements a Windows NT-style kernel and aims to run Windows applications and drivers without using Microsoft’s Windows code. A Windows-compatible operating system that could read NTFS but could not live on it had an obvious architectural and practical gap.
The missing NTFS features still matter
The driver is not equivalent to the NTFS implementation in modern Windows. The project cautions that caching, journaling and filesystem security support are still absent, and that additional bugs are likely to surface.
- No caching: repeated reads and writes cannot rely on a mature filesystem cache, so storage performance can be noticeably worse than the underlying disk would suggest.
- No journaling: NTFS normally records pending metadata changes so the filesystem can recover more predictably after a crash or power loss. Without that protection, an interrupted write carries more risk.
- No security support: the driver does not yet provide the expected NTFS security model. A volume being readable by Windows does not mean ReactOS is enforcing Windows-style permissions and access controls in the same way.
Those are core filesystem behaviors, not finish-work. A successful install demonstrates that the driver can sustain the operating system’s normal file activity long enough to set up and boot. It does not establish production-grade durability, performance or permission enforcement.
Why the download version is important
The timing creates an easy trap for testers. The 0.4.16 release brought a graphical installer, a combined live-and-install image, a new ATA driver and broader hardware support, but its release branch was cut in April. The NTFS installation milestone came later on the active development branch.
The project’s own repository documentation still describes FAT16 or FAT32 as the default installation requirement and Btrfs as experimental. That apparent contradiction is a version boundary: the release download favors the tested 0.4.16 snapshot, while nightly images are built from newer commits and are more likely to contain regressions.
Anyone trying the NTFS installer should confirm that they have a sufficiently recent nightly build. If Setup does not offer the expected NTFS path, the first thing to check is the build date rather than assuming the feature has failed.
How to test ReactOS on NTFS safely
A disposable virtual machine is the sensible starting point. ReactOS itself recommends virtualization or a computer with no sensitive data, and that warning becomes more important when testing an incomplete filesystem driver.
- Create a new VM and blank virtual disk. Do not reuse a virtual disk that contains another operating system or attach a physical Windows volume.
- Take a snapshot before installation. Keep the original disk state available in case Setup, the driver or a later application write corrupts the volume.
- Use a current nightly image. The official 0.4.16 image is useful for comparing behavior, but it predates this development milestone.
- Confirm the filesystem in Setup. Record the build number and the format option used. A bug report without those details will be difficult to reproduce.
- Test storage before applications. Create, rename, copy and delete files of different sizes; reboot normally; then verify that directories and file contents remain intact.
- Keep host integration limited. Avoid shared folders, pass-through disks and credentials until the guest has proved stable enough for the specific experiment.
Testing application compatibility is a separate exercise. ReactOS remains focused on Windows Server 2003-era behavior even as it gradually adopts newer APIs and synchronizes parts of its user-mode stack with Wine. An application launching successfully says little about modern driver support, security hardening or filesystem resilience.
What would make NTFS support ready for wider use
The next meaningful milestones are less visible than the installer screen: working caching, crash recovery through journaling, NTFS security semantics, sustained test coverage and a release that formally includes the new driver behavior. Hardware compatibility also remains a parallel constraint.
ReactOS 0.4.16 showed how much of that surrounding work is still moving. Its new ATA driver was intended to avoid slow boots and INACCESSIBLE_BOOT_DEVICE failures seen with the older UniATA path, including better operation in Hyper-V Generation 1. The release also continued a gradual Wine 10 synchronization, while normal release images still expose Windows Server 2003-era exports.
NTFS installation is consequently a real engineering milestone with a narrow meaning. ReactOS can now occupy the same basic filesystem format as Windows, but the protections users associate with that format are not all present. For developers and operating-system enthusiasts, that opens a useful new testing surface. For everyone else, the responsible headline is simpler: ReactOS has removed a long-standing blocker, and it is still an alpha.
