Copy source to destination within the disk.
Delete path. Resolves to whether something was actually deleted.
Whether a file (or object) exists at path.
List the file paths under directory (relative to the root), optionally recursively.
Read the raw bytes at path.
Read the content at path decoded as text.
The last-modified time (epoch ms) of path, if known.
Ensure a directory/prefix exists.
The best-effort MIME type of path, if known.
Move/rename source to destination within the disk.
ReadonlynameA human-readable disk name (e.g. 'local', 's3'), used by the StorageManager.
Write content to path, creating parent directories/prefixes as needed (overwrites).
Open a readable stream for path (streaming large objects without buffering).
The size in bytes of path.
Full metadata for path.
A URL for path (a file:// URL locally; a public/presigned URL for object stores).
Write a readable stream to path.
Agnostic storage-driver contract for Stone.js.
This is the abstraction that makes the filesystem layer backend-independent: the local disk (LocalFileSystem) implements it today, and a future
S3FileSystem(or GCS, Azure Blob, R2, in-memory…) implements the exact same interface. Application/domain code depends only onFileSystem, never onnode:fs, so switching or mixing backends is a configuration concern (see StorageManager), not a code change.Every operation is async — object stores are inherently network-bound, and even the local driver uses non-blocking I/O so a file operation never stalls the event loop. Paths are always relative to the driver's root (its "disk"/"bucket"); a driver MUST confine access to that root.