# RFile vs Windows File Explorer: benchmark evidence

> Evidence status: 2026-08-26. This page separates a retained July 2026 transfer-engine
> experiment from any claim about the current RFile and File Explorer interfaces.

## What the evidence supports

In one historical, protected **E: to C:** copy experiment, direct Windows
**`robocopy.exe /MT:16`** copied a fixed 40,373-file tree with a median conservative completion time
of **66.210 seconds**. The Windows Shell `IFileOperation` implementation used for the Explorer-style
comparison took **215.166 seconds** using the harness's conservative completion measure.

For this exact workload and machine only, that is:

- **148.956 seconds less median time** for direct Robocopy;
- **69.2% lower median completion time**; and
- **3.25× the median conservative throughput**: 251.528 MiB/s versus 77.399 MiB/s.

Those figures describe the same result in inverse forms: elapsed time is lower-is-better,
while throughput is higher-is-better.

This result is **not** a current RFile 0.3.62 versus `explorer.exe` UI benchmark. The July harness
called the two engines directly. Its Robocopy cell represents the engine family RFile recommends
for eligible local transfers, but it did not traverse the current RFile application or its current
adaptive `/MT` selection policy; this historical cell fixed the worker count at `/MT:16`.
`IFileOperation` is the Explorer-style Windows Shell API, not a timing of `explorer.exe` or its UI.
The harness did not open either app, create tabs, render folders, measure interaction readiness, or
time copy commands issued through their interfaces. A fresh UI run was not executed on 2026-08-26
because the required Computer Use capability for driving and observing both Windows apps was
unavailable. No substitute shell-only timing is presented as a UI result. Schema 1 retained exact
probe/core hashes but no RFile app version; none of these historical engine cells is today's Tauri
application.

## Retained comparison

### Workload

| Property | Exact retained value |
| --- | ---: |
| Operation | Cross-volume copy, E: source clone to C: destination |
| Files | 40,373 |
| Directories, including root | 2,474 |
| Bytes | 17,462,590,143 bytes |
| Decimal / binary size | 17.46 GB / 16.26 GiB |
| Measured samples | 3 clean samples per engine |
| Content-manifest SHA-256 | `4255687DED4018B5846D3643EFD1D6FBA9C7D2767BE76FB21E29C89383BD3B4B` |
| Metadata-manifest SHA-256 | `557157E93E7085053769689FB62F2CA5514FC8FFB1886FF1D3E19AC541292B1E` |
| Ordinal-tree BLAKE3 | `042431C91AD8D6E2052D3E7C2EF326677DF7615BF0789A0A2819AC9C67DDD49B` |

The original source tree was never passed to any measured engine. Before each sample, the harness
made a fresh marker-owned clone on E:, verified it against the retained manifests, created a new
marker-owned destination on C:, ran one engine, verified the result, and removed only the guarded
run directories.

### Summary

| Metric | Direct `robocopy.exe /MT:16` | Windows Shell `IFileOperation` |
| --- | ---: | ---: |
| Clone preparation median, excluded from throughput | 40.147 s | 41.101 s |
| Planning median | 0.009 s | 0.052 s |
| Cache-accepted transfer median | 24.022 s | 168.047 s |
| Explicit post-copy file flush median | 42.835 s | 46.953 s |
| **Conservative completion median** | **66.210 s** | **215.166 s** |
| **Conservative throughput median** | **251.528 MiB/s** | **77.399 MiB/s** |
| Engine CPU time median | 80.078 CPU-s | 166.688 CPU-s |
| Process CPU, total-machine normalized | 7.557% | 4.685% |
| System CPU, total-machine normalized | 91.430% | 63.919% |
| Exact content validation | 3/3 | 3/3 |
| Retained metadata-manifest match | 3/3 | 0/3 |
| Guarded cleanup validation | 3/3 | 3/3 |

Both direct-engine process-completion values were only cache/filesystem-accepted boundaries. The
harness made the comparison more conservative by adding a separate `FlushFileBuffers` pass over
every published ordinary file after each engine exited. That does **not** prove directory durability
or give either direct cell RFile's recovery-journal semantics, and Windows did not expose an
equivalent directory flush in this harness. The same per-file flush procedure was applied to both
direct cells, but their underlying engine semantics are not identical.

The metadata result means only that the destination did or did not match this experiment's
attributes-and-last-write-time manifest. It is not a claim that every type of Windows metadata was
tested.

### Raw clean samples

The composite keeps rotations 1 and 3 from the original report and replaces the excluded original
rotation 2 with the clean hardened replacement. Lower completion time and higher throughput are
better.

| Sample | Engine | Conservative completion | Conservative throughput | Exact content | Metadata manifest |
| --- | --- | ---: | ---: | --- | --- |
| Original rotation 1 | Direct Robocopy `/MT:16` | 66.870384 s | 249.043339 MiB/s | pass | match |
| Replacement rotation 2 | Direct Robocopy `/MT:16` | 66.209790 s | 251.528116 MiB/s | pass | match |
| Original rotation 3 | Direct Robocopy `/MT:16` | 64.167867 s | 259.532138 MiB/s | pass | match |
| Original rotation 1 | Windows Native (`IFileOperation`) | 215.165689 s | 77.399068 MiB/s | pass | mismatch |
| Replacement rotation 2 | Windows Native (`IFileOperation`) | 223.549189 s | 74.496462 MiB/s | pass | mismatch |
| Original rotation 3 | Windows Native (`IFileOperation`) | 198.896517 s | 83.730092 MiB/s | pass | mismatch |

An unrelated workspace read overlapped the original rotation-2 Windows Native timing, so the
entire three-engine rotation was excluded rather than selectively keeping favorable cells. The
replacement preserves the counterbalanced order.

### Supplemental third-engine result

The same clean composite also measured the historical production-journal transfer-service core
labeled **Velocity Rust (Beta)**. Its median conservative completion was 184.303 seconds and its
median conservative throughput was 90.360 MiB/s, with exact content, retained metadata, and guarded
cleanup passing 3/3. Unlike the two direct external-engine cells, that terminal boundary included
the old core's device-durable transfer boundary and `synchronous=FULL` journal completion. It is
retained as supplemental engineering context, not the headline RFile-versus-Explorer-style result
and not evidence about the current Tauri application's UI.

## Method and evidence files

The schema-1 harness used a cyclic Latin order across Velocity Rust, Windows Native, and Robocopy,
so each engine ran first, middle, and last once. This public comparison leads with the direct
Robocopy and Windows Native cells. Fixture preparation, pre-engine integrity work, planning, transfer,
explicit flush, post-copy validation, and cleanup were timed separately. Preparation and validation
were excluded from throughput. Exact file counts, byte counts, content hashes, metadata manifests,
and guarded cleanup were pass/fail gates.

Public evidence:

- [Sanitized raw samples and summary](./rfile-vs-explorer-raw.json), including all nine clean
  three-engine cells (six headline Robocopy/Windows cells plus three supplemental Velocity cells),
  the excluded-rotation reason, exact fixture digests, and the limitations used by the landing page;
- original report SHA-256
  `0D06874FFDBDF110D00ED9B1861D5F0D4A15AF9EC0F753E7A8AC693426A92C70`;
- clean replacement-rotation SHA-256
  `763AAF01C9B6D213562530CCD0F753C67D664C863CC23E1DF20BA44152F52315`; and
- contamination-record SHA-256
  `5C96C29349377D7F61118DC2D56C5FD5CD835F58356FFF7B9A96A302B84104EF`.

The repository retains the full original reports, content and metadata manifests, protected-tree
safety model, and the explanation of why schema 1 does not satisfy the newer schema-3 release
gates. The public JSON deliberately omits local absolute paths while preserving every clean sample
used here.

The historical executable provenance recorded in both raw reports was:

| Role | Retained identity |
| --- | --- |
| Direct Windows Robocopy | System32 `robocopy.exe`; schema 1 did not retain its SHA-256 |
| Velocity production-journal test executable | `841D8D0C95C51FE989BC3EA9BF697B1F2A2FD2A939DFB53ED7CD66E74641112E` |
| Windows Native probe | `E6EC5608FA90BE55AC058F0EBB9EF1AC6C31052DC91DE532DF9E9A9C5E0D541E` |

The hashes identify the historical core/probe binaries, while the schema-1 Robocopy record retains
only its System32 path. Schema 1 did not record an RFile app version, and none of these historical
cells identifies the current Tauri application or its executable hash.

## Current provenance snapshot — not a performance sample

Captured on 2026-08-26:

| Item | Current value |
| --- | --- |
| Installed RFile | 0.3.62, 61,923,328 bytes |
| Installed RFile path | `%LOCALAPPDATA%\RFile\rfile-desktop.exe` |
| Installed RFile SHA-256 | `7BA2AA2A77DF14EBC0BB4BD2F2A1A6B32D2AB4C074CB3AFDA53317D2900A3035` |
| Windows Explorer | `%WINDIR%\explorer.exe`, 3,373,256 bytes |
| Explorer file version | 10.0.26100.8117 (WinBuild.160101.0800) |
| Explorer SHA-256 | `C5E95F643581FFD5EDA5B6BAC0DEA664208357037E074D65CDE6D5F10BC2C083` |
| OS | Windows 11 Home 10.0.26200, build 26200 |
| Machine | Alienware Aurora R12 |
| CPU | Intel Core i7-11700KF, 16 logical processors |
| Physical memory | 68,378,025,984 bytes (about 63.68 GiB) |
| Current E: volume | NTFS, 3,999,895,908,352 bytes total |
| Current C: volume | NTFS, 1,023,248,691,200 bytes total |

The present inventory reports a Samsung SSD 990 EVO Plus 4TB, Kingston SA400S37240G, and WD SN730
NVMe. It does not establish which physical device backed each historical logical volume. The July
schema-1 reports did not retain a complete OS/hardware snapshot, so current machine values must not
be backfilled as if they had been captured during those samples.

## Feature comparison: evidence, not red-X marketing

The benchmark proves only one historical copy-engine workload. Feature presence is a separate
question. The table below records what can be linked to current RFile repository evidence and
current Microsoft documentation; it deliberately avoids claiming that an undocumented or untested
Explorer feature is absent.

| Capability | RFile evidence | Windows Explorer evidence | Safe conclusion |
| --- | --- | --- | --- |
| Tabbed file browsing | RFile documents [tabs](/docs/tabs) and detachable workspaces. | Microsoft documents an open-tab area and add-tab control in [File Explorer navigation](https://support.microsoft.com/en-us/accessibility/windows/use-a-screen-reader-to-explore-and-navigate-file-explorer-in-windows) | Both support tabs; opening-tab speed was not measured. |
| Two simultaneous file panes | RFile documents [split view](/docs/split-view). | No equivalent feature audit was run in this session. | RFile evidence exists; no Explorer red X is justified here. |
| Selection preview | RFile documents its [Inspector](/docs/inspector) and supported formats. | Microsoft documents the File Explorer preview panel through `Alt+P` in [Windows keyboard shortcuts](https://support.microsoft.com/en-us/windows/keyboard-shortcuts-in-windows-dcc61a57-8ff0-cffe-9796-cb9706c75eec) | Both have preview concepts; format support differs. |
| Nearby file transfer | RFile documents [Nearby Sharing](/docs/nearby-sharing). | Microsoft documents Bluetooth/Wi-Fi [Nearby sharing](https://support.microsoft.com/en-us/windows/share-things-with-nearby-devices-in-windows-0efbfe40-e3e2-581b-13f4-1a0e9936c2d9) | Both offer nearby transfer; protocol, security, range, and speed were not compared. |
| Copy, move, rename, create, and delete | RFile documents its [file-transfer paths](/docs/file-transfers) and the retained copy evidence above. | Microsoft documents those Shell operations in [`IFileOperation`](https://learn.microsoft.com/en-us/windows/win32/api/shobjidl_core/nn-shobjidl_core-ifileoperation) | Core operation availability is shared; only historical copy-engine speed was measured. |
| Transfer backend choice and recovery journal | RFile documents selectable engines, verification, and recovery behavior in [file transfers](/docs/file-transfers). | Explorer UI configurability and recovery semantics were not audited. | Document the RFile capability without claiming an unverified Explorer absence. |

Documentation links describe the current public product contract. Matching version strings do not
provide a cryptographic source-to-installed-binary attestation, and the current UI was not exercised
in this session. A website checklist should preserve labels such as **verified**, **documented**,
and **not audited** instead of converting unknowns into crosses.

## Limitations

- Three clean samples per engine are useful decision evidence, but too few for a broad hardware or
  workload claim.
- The run used one real tree, one E:-to-C: volume pair, and one machine.
- Cache state, Microsoft Defender, unrelated background I/O, firmware behavior, thermal state, and
  power policy were not controlled.
- The workload was a copy. It did not test move, delete, rename, archive work, cloud storage,
  network shares, removable media, or failure recovery under physical faults.
- The direct `IFileOperation` probe exercised the Windows Shell implementation used for
  Explorer-style operations; it did not launch or time the File Explorer UI.
- The completion boundaries were deliberately conservative but not semantically identical.
- The historical direct Robocopy cell fixed `/MT:16`; it did not exercise RFile 0.3.62, the current
  Tauri request path, or today's adaptive Robocopy worker policy. Current application performance
  may be better, worse, or unchanged.
- No fresh tab, folder-opening, scrolling, preview, startup, memory, or UI transfer test was run on
  2026-08-26.

The supported claim is therefore narrow: **historical direct `robocopy.exe /MT:16` beat the
Windows Shell `IFileOperation` probe using the harness's median conservative completion measure for
this one retained 17.46 GB multi-file copy cell.** It is representative of RFile's recommended
Robocopy engine family, not evidence that the current RFile application is generally faster than
Windows File Explorer.

## Reproducible future RFile-versus-Explorer UI protocol

Use this protocol when the required Windows app-control capability is available. Publish its raw
machine-readable report before adding any current UI claim to the website.

### 1. Pin the environment

1. Record UTC start/end time; RFile and `explorer.exe` paths, versions, sizes, and SHA-256 hashes;
   Windows edition/build; machine model; CPU; RAM; logical-volume filesystems/free space; physical
   disk inventory; display scaling; active power mode; Defender state; and foreground/background
   process load.
2. Use one unlocked local desktop and one display configuration for the complete rotation.
3. Start each app once and verify keyboard focus and the exact starting folder before measuring.
4. Do not describe a sample as cold-cache unless cache eviction is independently proven. Keep warm
   and after-reboot cells separate.

### 2. Generate safe, identical fixtures

Create randomized marker-owned roots under explicit benchmark parents. Never operate on a user's
original tree. Recommended cells are:

- an empty folder for tab creation;
- a deterministic 10,000-entry mixed folder for navigation-to-first-row and navigation-to-settled;
- one deterministic 4 GiB ordinary file for large-file transfer; and
- a deterministic 40,000-file tree with recorded count, bytes, relative paths, attributes,
  last-write times, and per-file hashes for small-file transfer.

Give every measured copy a fresh destination. Verify source and destination manifests outside the
timed window. Retain the fixtures on any failed safety or identity check.

### 3. Use equivalent UI boundaries

| Cell | Start boundary | End boundary |
| --- | --- | --- |
| Open a tab | accepted `Ctrl+T` input in an already-running focused app | new tab is selected and its content surface exposes the expected empty-folder state |
| Open a populated folder | accepted `Enter` on the same selected folder | report both first expected row usable and full expected item count settled |
| Large-file copy | accepted paste command after the same source selection has been copied | app transfer UI is terminal, destination handle is closed, and expected length is observable |
| Many-file copy | accepted paste command after the same source tree has been copied | app transfer UI is terminal and the expected destination count/bytes are observable |

Timestamp the injected input and observed UI state with one monotonic clock. The automation must
confirm the expected app, window, focus, starting path, selection, and destination for every sample.
Filesystem polling may corroborate transfer completion, but it must not replace the app's terminal
UI state. Hash and metadata validation remain outside the timed window.

RFile and Explorer may choose different default locations for a new tab. Record the actual target
shown by each app. Compare tab-ready numbers as an equivalent workload only if both can expose the
same declared target; otherwise publish the two app-default timings descriptively without naming a
winner.

### 4. Counterbalance and repeat

1. Run two separately labeled warmups per app and cell. Exclude them from the measured summary but
   retain their raw timings.
2. Run at least ten measured samples per app and cell using an alternating, position-balanced order;
   a mirrored sequence such as R/E, E/R, E/R, R/E is the minimum acceptable pattern.
3. Use a fresh tab or destination for each sample. Do not delete one app's output while timing the
   other.
4. Pause between transfer cells until destination activity returns to a declared idle threshold.
5. If antivirus, update installation, indexing, user input, or unrelated heavy I/O overlaps a
   sample, exclude the complete paired rotation and retain a contamination record.

### 5. Report without cherry-picking

Publish every raw sample, warmup status, exclusion reason, correctness result, and environment
field. For each app/cell report median, minimum, maximum, and a declared percentile rule (for
example nearest-rank p95). Include absolute and relative differences, but name a winner only for the
measured cell. If boundaries are not equivalent, confidence intervals overlap materially, or
correctness fails, report **inconclusive** rather than a speedup.