Inspect Project File Systems

Find out where an existing Project keeps the Resources it created on its file system, and clean up the folders, called mounts, that dropped Resources leave behind. To choose where a Project stores new Tables, select a Volume for it instead; see Store Tables on a Volume.

A Project's file system can no longer be changed. Both POST /v1/file-systems/{project_id} and POST /v1/file-systems/{project_id}/update return 410 Gone with a JSON message directing callers to Volumes. To store a Project's data in your own bucket, register the bucket as a Volume and select that Volume for the Project. Rotate storage credentials on the Volume.

Before you startCopy Anchor Link

• Permission to view the Project's file system.
• The CLI, signed in with spiral login, or an access token in $SPIRAL_TOKEN.

Show the current file systemCopy Anchor Link

curl "https://api.spiraldb.dev/v1/file-systems/demo" \
  -H "Authorization: Bearer $SPIRAL_TOKEN"

To see the providers that a builtin file system can use, run spiral fs list-providers, or send GET /v1/file-systems/builtin-providers.

List the mountsCopy Anchor Link

Each Resource that a Project created on its file system has one mount:

for mount in client.storage.list_mounts_items("demo"):
    print(f"{mount.id}: {mount.alias} at {mount.directory} ({mount.mode})")

Inspect one mount with spiral fs mounts info <MOUNT_ID>, or send GET /api/storage/mounts/{mount_id}.

Remove a mountCopy Anchor Link

Removing a mount cuts off access to its folder at once, and the Resource that owns it can no longer read or write its files. Remove a mount only after you have dropped its Resource and no pinned commit still needs it. Then run spiral fs mounts rm <MOUNT_ID>, or send DELETE /api/storage/mounts/{mount_id}.