fast_ntfs Rust crate
THIS FORK USES AI!
original by Colin Finck <colin@reactos.org>
A low-level NTFS filesystem library implemented in Rust.
fast_ntfs is a fork of the ntfs crate that adds caching,
buffer reuse, fast path lookup, and robustness improvements on top of the upstream library.
Most upstream APIs remain source-compatible apart from imports changing from ntfs::... to
fast_ntfs::...; the fork also provides additional optimized APIs.
NTFS is the primary filesystem in all versions of Windows (since Windows NT 3.1 in 1993). This crate is geared towards the NTFS 3.x versions used in Windows 2000 up to the current Windows 11. However, the basics are expected to be compatible to even earlier versions.
The crate is no_std-compatible and therefore usable from firmware-level code up to user-mode applications.
ntfs-shell

The ntfs-shell example comes with this crate to demonstrate all library features.
Use it to explore the internal structures of an NTFS filesystem at any detail level, even of your running Windows partition.
No artificial security restrictions will block you from accessing files and folders, extracting their data or Alternate Data Streams.
The filesystem is opened read-only, so you can safely browse even a mounted filesystem without worrying about data corruption.
That is also helpful to get an idea of the Windows NTFS driver, e.g. to find out when its lazy writer actually updates the data on disk.
I originally wrote ntfs-shell for myself to comfortably develop the library in user-mode before running the code in production in kernel-mode.
To build ntfs-shell, just clone this repo and call
cargo build --example ntfs-shell --all-features
To run it, pass the path to an NTFS image (on all operating systems) or to a partition (like \\.\C:, on Windows only with administrative privileges) to the resulting ntfs-shell binary.
Calling help gives you a list of all supported commands.
help COMMAND details the syntax of that command.
Most commands that take a filename also take an NTFS File Record Number (if prepended by /).
This File Record Number may be decimal or hexadecimal (if prepended by 0x).
Some examples:
fileinfo Windows
fileinfo /146810
fileinfo /0x23d7a
Library Features
- For the impatient: Convenience functions to treat NTFS like any other filesystem and just read files and directories using
Read/Seektraits. At your option, you may also explore the filesystem at any detail level. - Reading arbitrary resident and non-resident attributes, attributes in Attribute Lists, and attributes connected over multiple Attribute List entries, including sparse attribute data. All of this together enables reading file data and Alternate Data Streams of any size and on-disk structure.
- Iterating over a flattened "data-centric" view of the NTFS Attributes, abstracting away any nested Attribute List.
- Efficiently finding files in a directory, adhering to the filesystem's $Upcase Table for case-insensitive search.
- In-order iteration of directory contents at O(1).
- Leveraging Rust's typesystem to handle the various types of NTFS indexes in a typesafe way.
- Error propagation through a custom
NtfsErrortype that implementsDisplay. Where it makes sense, variants have additional fields to pinpoint any error to a specific location. - Full functionality even in a
no_stdenvironment withalloc. - No usage of
unsafeanywhere. Checked arithmetic where needed. - Platform and endian independence.
Not yet supported
- Any write support
- Compression
- Encryption
- Journaling
- Quotas
- Reparse Points
- Security Descriptors
Examples
The following example dumps the names of all files and folders in the root directory of a given NTFS filesystem.
The list is directly taken from the NTFS index, hence it's sorted in ascending order with respect to NTFS's understanding of case-insensitive string comparison.
use Ntfs;
let ntfs = new.unwrap;
let root_dir = ntfs.root_directory.unwrap;
let index = root_dir.directory_index.unwrap;
let mut iter = index.entries;
while let Some = iter.next
For repeated File Record or path lookup, create a resolver. Paths are root-relative and accept
either / or \ separators. with_path reuses the same File Record buffer for every component:
use Ntfs;
let ntfs = new.unwrap;
let mut resolver = ntfs.file_resolver.unwrap;
resolver
.with_path
.unwrap;
Check out the docs, the tests, and the supplied ntfs-shell application for more examples on how to use the fast_ntfs library.
Benchmarking
The benchmarks use the checked-in testdata/testfs1 image so that runs are reproducible and do not depend on a local NTFS volume.
Reference results for the 512-entry many_subdirs directory are shown below. Times are
machine-dependent; these before/after measurements were produced on the same Windows host with the
same Rust toolchain and the optimized benchmark profile.
| Operation | Original time | Current time | Original allocations | Current allocations | Original bytes | Current bytes |
|---|---|---|---|---|---|---|
| Iterate 512 entries | ~32.4 us | ~15.6 us | 25 | 6 | 86,360 | 8,600 |
| Find all 512 entries | ~1.41 ms | ~121 us | 1,518 | 51 | 4,128,792 | 110,704 |
| Repeat all 512 with a hot finder | — | ~106 us | — | 0 | — | 0 |
NtfsIndexFinder caches loaded subnodes and builds a compact entry index for binary search. The
entry index adds one allocation per cached node, but reduces the 512-entry find-all runtime by about
91% while keeping allocation count and cumulative allocated bytes about 97% below the original
implementation. Reusing the finder makes subsequent passes allocation-free. Directory index
construction allocates 3 times / 216 bytes for this fixture. NtfsFileResolver performs repeated
cached File Record loads without per-lookup allocation.
Run the statistical execution-time and throughput benchmarks with:
Criterion stores its report under target/criterion. To compare an optimization against a saved baseline, run:
# Make the code change, then compare it with the saved baseline.
Run the deterministic allocation benchmark with:
It reports allocation count, cumulative allocated bytes, and bytes retained at the end of each operation. Build and run benchmarks on an otherwise idle machine, and compare results produced with the same Rust toolchain and target.
License
This crate is licensed under either of
at your option.
Unless you explicitly state otherwise, any contribution intentionally submitted for inclusion in the work by you, as defined in the Apache-2.0 license, shall be dual licensed as above, without any additional terms or conditions.