Trash & recovery

Understanding the “delete” operation

Deleting a file or directory moves that inode to the trash. Deleting a non-empty directory without using the “recursive” option will raise an error. Files and directories can be restored from within the trash on demand.

Listing items in the trash

Items in the trash can be enumerated using the List trash API or loonfs trash. Each entry includes inode_id (such as ino_42), inode_kind, deletion_seq, deleted_by, and deleted_at_ms. The required deleted_binding names the parent inode and display name the deletion removed.

Undeleting items from the trash

Items can be recovered with undelete. Both inode_id and deletion_seq are required so a stale request cannot undo a later deletion of the same inode. By default, undelete restores the recorded binding under the same parent inode and display name it had before deletion. Because the recovery record keeps the parent identity rather than an old path string, this still works when an ancestor was renamed.

loonfs undelete --inode ino_42 --deletion-seq 417

See the undelete request schema in the Apply a commit API docs for details.

Entries in the trash are protected from garbage collection independently of the WAL retention floor.

A successful undelete creates a new path binding and therefore a new binding_version.

Trash recovery vs. revision restoration

Files can be deleted (sent to the trash), and replaced with newer revisions. The operations to recover the previous state are different:

• To recover a deleted file → undelete (this page).
• To recover an earlier version of an existing file → restore_revision, see Revisions.