Jamie PineandClaude Opus 5 7d41e07ab9 Read files from the arena, not from entries
Every query that answered from `entry` now answers from the volume index,
which is the one that knows about the whole drive. Each of these had both
paths already and picked between them at runtime; the entries branch was
the one that only worked where someone had added a location.

search collapsed hardest. IndexType existed to choose between an FTS5 index
over entries and the in-memory one, and there is only the one now, so fast,
normal and full modes were three routes to the same table. A library-wide
search fans out over every partition, which is the search that was never
possible before: it used to mean "every location you added".

SearchScope loses Location. Nothing called it, and under the demotion a
location is a subtree rather than a thing you search inside.

files.media_listing walks the arena instead of joining four tables, and
sorts DateTaken by birth time, which is the closest thing the arena knows
and the one a photo library actually wants.

files.alternate_instances asks content identity rather than content_id, so
it spans drives: every source is asked about the same content uuid and they
agree because the id comes from the bytes. Two new store queries back it,
content_of and copies_of_content.

Copy estimates read subtree_bytes and file_count off the arena. Those
rollups are maintained as the arena is written, so the progress bar gets its
numbers from a lookup rather than from a walk.

files.unique_to_location had no callers and no meaning once a location stops
owning records.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
2026-09-09 18:25:30 -07:00
2026-08-21 13:47:42 -07:00
…
2026-09-09 04:21:15 -07:00
2026-08-21 13:47:42 -07:00
…
2026-08-21 13:30:04 -07:00
2026-08-21 13:30:04 -07:00
…

Spacedrive

Spacedrive

More space, from the drives you already have.

docs.spacedrive.com • Discord • Files • Getting Started • Status


Note

August 2026: Version v2.0.0-alpha.4 is out now!

Spacedrive is a lightweight, Rust native, file manager that connects your devices, drives and clouds into one virtual file system. Pool your storage capacity together and browse and search drives that aren't even plugged in.

Backed by a continiously updating, modular index. Spacedrive can walk all major file systems, extracting metadata and snapshotting drive state without touching the files.

Mount anything to your Mac or PC. Like screenshots shared between several computers, or a project with 10TB of raw footage shared with a team. File content streams from one device to another on-demand.

The mission

The file system has been the single most important part of computing from the start, but software has become increasingly dependent on cloud services at the cost of data ownership.

This is a software problem, Spacedrive is here to solve it.

Files

The file manager of that computer, built on an index that Spacedrive maintains continuously. The watcher feeds it as files change, so it is already current when you look — nothing is built on demand while you wait.

Every surface is a view over that one index: grid, list, columns, media, size, recents, search, knowledge. A size analysis of a folder and a photo grid of the same folder are the same data through a different lens, and each view opens current because the index already is.

  • One address for everything. Every file has an SdPath, whether it lives on this machine, another of your devices, or a cloud volume. Operations work the same across all of them.
  • Content identity. BLAKE3 hashing gives the same file on two machines the same fingerprint — the basis for deduplication and redundancy tracking across your machines.
  • Cloud volumes as first-class storage. S3, Google Drive, Dropbox, OneDrive, Azure Blob and GCS get indexed alongside local disks.
  • P2P sync. Devices connect directly over Iroh and QUIC with no server in the middle. Metadata syncs, files stay where they are, and devices that are offline remain in the index.
  • Search that works. SQLite FTS5 over files and archived records, roughly 55ms on a million entries, with indexing at around 8,500 files per second.
  • Preview before commit. Copies, moves and deletes are simulated first, so you see conflicts and space changes before anything runs, and the operation becomes a durable job that survives restarts.

Files runs standalone: a desktop app on macOS, Windows and Linux, iOS and Android clients, a browser client, a headless server and a CLI. The macOS install is 44.4 MB with no bundled codecs and nothing to download. V2 is in alpha; the last stable download is v1.

It is machine-scoped by design. A host has one filesystem, so it gets one index, and everything else on the machine declares against that index as a capability instead of running an indexer of its own.

Search everything, not just files

Archive indexes external sources through script adapters, which puts email, notes, bookmarks and chat history in the same index as your files. Shipped adapters: Gmail, Apple Notes, Chrome Bookmarks, Chrome History, Safari History, Obsidian, OpenCode, Slack, macOS Contacts, macOS Calendar and GitHub.

Writing one means a directory with an adapter.toml and a script in any language that reads stdin and prints lines. See docs/archive/README.md.


Where V2 came from

2021. A personal project: one interface over files scattered across devices and cloud accounts, with content-addressed identity so the same file on two machines is the same file.

May 2022. Open sourced. Number one on GitHub Trending for three days, 10,000 stars in the first week, a $2M seed round, a team of around twelve.

Early 2025. 35,000 stars, 600,000 installs, and a codebase that could no longer ship. The Rust Prisma client was deprecated with no migration path, libp2p transfers hung in ways nobody could debug, and two incompatible file models meant every operation needed writing twice. docs/overview/history.mdx is the full post-mortem.

2025. V2, rebuilt solo against that list. SeaORM for Prisma, Iroh for libp2p, one SdPath for every file, jobs down to about 50 lines each, and search that actually searches.

2026. The subtraction. V2 fixed V1's engineering and kept its appetite: every install compiled in a WASM extension runtime and shipped a bundled media stack, on the theory that a file manager should carry its whole environment. It should not, and both became opt-in:

macOS payload before ~156 MB (73.2 MB binary plus an 83 MB framework)
Default install now 44.4 MB, one file, nothing to download

Nothing was removed from the product. The heavy subsystems became opt-in features, macOS thumbnails route through ImageIO and QuickLook instead of bundled FFmpeg and libheif, and half the old binary turned out to be data rather than code. Every number is measured; the method is in docs/plans/2026-07-29-install-size.md.


Status

Under active development, and in alpha. V2 is a rebuild rather than a patch, so treat everything below as moving.

Files: indexing, sync, cloud volumes, desktop, mobile and web clients working
Archive: record table, durable overlay, FTS5 search, 11 adapters working
Machine-scoped daemon: supervision, health, lifecycle, port leases working
Mounts: read-only share on loopback, byte-range peer protocol in progress
Per-source stores and the in-memory read tier in progress

Architecture

spacedrive/
├── core/                  # Rust engine (CQRS/DDD): indexing, sync, jobs, volumes
├── crates/                # archive, supervisor, task-system, crypto, imageio, images
├── apps/
│   ├── tauri/  mobile/    # Desktop (macOS, Windows, Linux), React Native
│   ├── cli/  server/      # CLI, daemon, headless server
│   ├── native/            # GPUI client prototype
│   └── web/               # Browser client
├── packages/
│   ├── interface/         # Files' React UI
│   └── ts-client/  swift-client/  assets/
└── adapters/              # Script-based data source adapters

Every core operation — a file copy, a tag create, a search query — is a registered action or query with type-safe input and output, and Specta generates the TypeScript and Swift clients from those definitions.

Component Technology
Engine Rust, Tokio
Database SQLite (SeaORM + sqlx)
Search SQLite FTS5
Content hashing BLAKE3
P2P Iroh (QUIC, hole-punching, local discovery)
Cloud storage OpenDAL (S3, Google Drive, Dropbox, OneDrive, Azure Blob, GCS)
Cryptography Ed25519, X25519, ChaCha20-Poly1305, AES-GCM
Media ImageIO and QuickLook on macOS, FFmpeg/libheif/Pdfium elsewhere
Desktop Tauri 2
Mobile React Native + Expo
Frontend React 19, Vite, TanStack Query, Tailwind CSS v4
Design system SpaceUI
Type generation Specta (TypeScript + Swift)

Getting Started

Requires Rust (stable, MSRV 1.81), Bun 1.3+, Node 20.x, and just.

git clone https://github.com/spacedriveapp/spacedrive
cd spacedrive

# System dependencies: cmake on macOS, GTK/WebKit/gstreamer on Linux.
# Pass `mobile` to also add the iOS/Android Rust targets.
./scripts/setup.sh              # .\scripts\setup.ps1 on Windows

bun install
cargo run -p xtask -- setup

xtask setup writes .cargo/config.toml, builds the release daemon, and registers the cargo xtask, cargo daemon and cargo cli aliases, so after the first run just setup does the same thing in one command. It downloads nothing.

On macOS that is everything you need. Thumbnails for video, HEIC, RAW and PDF come from ImageIO and QuickLook, the same system codecs Finder uses. Elsewhere those formats need the prebuilt codec bundle (FFmpeg, libheif, Pdfium), which is a 91 MB download and enables the ffmpeg and heif features:

cargo run -p xtask -- setup --native-deps

Run Files

just dev-desktop  # desktop app (builds and starts the daemon for you)
just dev-server   # headless server + web UI
just dev-mobile   # Expo dev server

Test and check

just test         # cargo test --workspace
just check        # cargo fmt --check + clippy

Python 3.9+ is needed at runtime by the bundled adapters, not to build Spacedrive.

Contributing


License

Apache-2.0.

Releases before 2026-03-24 were published under AGPL-3.0 and remain available under that license.

S
Description
No description provided
Readme Apache-2.0
400 MiB
0 Stars 1 Watchers 0 Forks
Languages
Rust 78.8%
TypeScript 18.2%
Python 1%
Swift 0.9%
Shell 0.3%
Other 0.7%