/** * Content-addressed file store for uploaded files. * * Files are stored on disk keyed by their sha256 hash. Two-level sharded * directory layout (`ab/cdef...`) keeps any single directory at a reasonable * size even after many uploads. * * Used by the import-file route handler to persist originals and Markdown * intermediates produced by converters. File identity is the content hash * returned by `put()`, which callers surface as `fileHash` and * `mdIntermediateHash` in the import-file response. * * Spec: 05_PROTOCOL_EXTENSIONS.md §6.5 */ export interface FileStoreEntry { /** * sha256 hash of the file contents, formatted as `sha256:`. * Used as the on-disk storage key for historical compatibility. */ hash: string; /** * keccak256 hash of the file contents, formatted as `keccak256:`. * Used on the wire and in the data/meta graph triples per * `05_PROTOCOL_EXTENSIONS.md §6.3` and `19_MARKDOWN_CONTENT_TYPE.md §10`. */ keccak256: string; /** Absolute path to the stored file on disk. */ path: string; /** Size of the file in bytes. */ size: number; /** MIME content type recorded at put() time. */ contentType: string; } export declare class FileStore { private readonly rootDir; constructor(rootDir: string); /** * Persist `bytes` to the store and return the resulting entry. Idempotent: * re-putting the same bytes returns the same hashes without rewriting the * existing blob. The `contentType` metadata is attached to the return * value but not persisted to disk — callers that need durable * content-type metadata should store it separately (e.g. in an `_meta` * triple keyed by hash). * * Content is stored under the sha256 shard layout. A small pointer file * under `keccak256/` is also written so the same blob is resolvable * by keccak256, which is the hash used on the wire and in graph triples. */ put(bytes: Buffer, contentType: string): Promise; /** * Retrieve the raw bytes for a previously-stored hash, or null if absent. * Accepts either the `sha256:` or `keccak256:` form. For * keccak256 inputs the pointer file written at put() time is dereferenced * to the underlying sha256 blob. */ get(hash: string): Promise; stat(hash: string): Promise<{ size: number; } | null>; readRange(hash: string, offset: number, length: number): Promise; /** Check whether a hash is present in the store. */ has(hash: string): Promise; /** * Resolve a hash to the underlying blob's on-disk path. Always returns * the CONTENT path regardless of which hash algorithm the caller * supplied: * * - `sha256:` or bare hex → the sharded blob path directly * - `keccak256:` → read the pointer file written at `put()` time, * deref it to the sha256 hex, return the sharded blob path for that * * Returns null for malformed hashes, for keccak256 inputs whose * pointer file does not exist, and for pointer files that contain * unexpected content. * * This is async because the keccak256 path requires a disk read. If * you specifically want the on-disk location of the keccak pointer * file (e.g. for integrity checks, debugging, or cleanup), use * `hashToPointerPath(keccakHash)` instead — that's synchronous and * returns null for non-keccak inputs. */ hashToPath(hash: string): Promise; /** * Resolve a `keccak256:` hash to its pointer-file path * synchronously, without dereferencing. Returns null for malformed * keccak256 hashes and for any other algorithm (use `hashToPath` to * get the content path for sha256). Intended for callers that want * to inspect or manipulate the keccak → sha256 indirection directly. */ hashToPointerPath(hash: string): string | null; private resolveKeccakPointerPath; /** Root directory the store writes into. */ get directory(): string; private resolvePath; } //# sourceMappingURL=file-store.d.ts.map