Skip to main content

Overview

Glyph’s storage system consists of:
  1. Space Files - User-created markdown files in notes/
  2. Assets - Content-addressed files in assets/ (SHA256 hash)
  3. Cache - Derived data in cache/ (link previews, thumbnails)
  4. Atomic Writes - Crash-safe file operations

Content-Addressed Storage

Why Content-Addressing?

Storing files by their SHA256 hash provides:
  • Deduplication - Same file stored once, even if used in 100 notes
  • Integrity - Hash mismatch = corrupted file
  • Immutability - Content can’t change without changing hash
  • Cache-friendly - Hash is permanent, perfect for CDNs

Implementation

src-tauri/src/notes/attachments.rs

Example

Frontend
If the same logo.png is attached to 10 different notes, only one copy exists on disk.

Atomic Writes

The Problem

Naive file writes can corrupt data if:
  • App crashes mid-write
  • Disk full during write
  • Power loss during write

The Solution

Write to temp file → fsync → rename → fsync parent directory.
src-tauri/src/io_atomic.rs

Usage

src-tauri/src/space_fs/read_write/text.rs

Path Safety

Preventing Path Traversal

All user-provided paths are validated:
src-tauri/src/paths.rs

Examples

Cache System

External link metadata is cached to avoid repeated fetching:
src-tauri/src/links/cache.rs

Space Structure Summary

.gitignore Recommendation

.gitignore

File Watching

Filesystem Watcher

src-tauri/src/space/watcher.rs

Performance Considerations

Large Files

For files >10MB, use streaming instead of loading into memory:

Batch Operations

Use database transactions for bulk inserts:

Next Steps

Tauri Commands

Learn IPC communication

Components

Frontend component structure