Take application state beyond one disposable machine

Applications rarely keep everything under one obvious directory. An emulator, launcher, creative tool, or game can read executables and content from one location while writing configuration, databases, saves, or generated state somewhere else. Noland's Linux state agent observes process and filesystem activity and correlates those facts with the active application session.

The observer reports facts such as process identity, operation, path, and time. The attribution and classification layers then decide what belongs in a backup. This keeps the mechanism generic: it can learn from an application's executable, child processes, reads, memory mappings, writes, creates, renames, truncates, and deletes without embedding a detector for each product.

• Executed files and direct read dependencies can become complete-application content
• Writes and other mutations provide stronger persistent-state evidence
• Child and reparented processes remain associated with the application session
• Sockets, pipes, caches, locks, and other volatile data are excluded

A complete-application export is intended to carry the application, directly used external content, configuration, and persistent state together. Personal-state mode focuses on user-created or mutated state while leaving reconstructable application and base-image content behind. The selected mode makes the tradeoff explicit instead of treating every file read as owned by the app.

Noland indexes file state, chunks and packs content, reuses unchanged chunks, and records resumable transfer progress. Encryption happens before upload, and the cloud catalog is committed only after the bundle objects are available. A bundle that never completes its catalog commit is not presented as a successful restore point.

• Complete application for executables, dependencies, content, and state
• Personal state for saves, settings, and other mutations
• Incremental planning avoids re-uploading unchanged content
• Operation progress, cancellation, retry, and reconciliation are exposed to the client

Restore uses the bundle catalog to plan materialization on the destination Linux host. Launch-critical files can be restored first so the application reaches a ready-to-launch milestone before lower-priority content finishes. The complete phase then materializes the rest of the selected bundle with its recorded paths, permissions, and ownership mapping.

Portability does not mean every host or application environment is interchangeable. The destination still needs compatible architecture, drivers, system packages, and runtime capabilities. Noland also cannot guarantee that third-party services, DRM, anti-cheat, or account-bound data will accept a moved environment.