Glitchpad

14. File Lifecycle and Data Integrity

File Lifecycle and Data Integrity requirements from the authoritative Glitchpad Technical Specification.

Opening creates a source handle, observes an external revision, detects the format, selects a renderer, publishes first content, and continues non-critical metadata work asynchronously. Closing disposes the renderer, cancels work, releases object URLs and workers, closes native handles, and removes recovery only after dirty-state resolution.

Desktop save writes a sibling temporary file, flushes content, preserves required permissions, atomically replaces the destination, and syncs the parent directory where the platform provides that primitive. If a platform or filesystem cannot atomically replace, Glitchpad MUST disclose the weaker guarantee before writing and retain a recoverable backup until the replacement succeeds.

Android save writes through a provider descriptor only when the source advertises safe write behavior. A read-only or unsafe provider source uses Save As through ACTION_CREATE_DOCUMENT. The application never truncates a provider source before a complete save payload and revision check are ready.

Before every save, Rust revalidates the external revision. A mismatch moves the session to conflicted, preserves local edits, and offers: compare available metadata, reload and discard local edits, keep local edits and Save As, or explicitly overwrite after a second confirmation. No default action overwrites either revision.

Rename, deletion, watcher overflow, permission revocation, provider unavailability, storage exhaustion, and partial I/O use stable error categories and preserve dirty content. Save success is recognized only from a durable host receipt carrying the new external revision.