import { WebDAV } from '@opencloud-eu/web-client/webdav';
/**
 * Wrap a WebDAV client so vault translation happens transparently on
 * every call: clear-text paths are encrypted on the way to the server, and the
 * encrypted names that come back are decrypted (and flagged) before any caller
 * sees them. Callers keep using `clientService.webdav` with clear-text paths and
 * never have to resolve a vault engine themselves.
 *
 * The wrapper is a strict pass-through whenever a path isn't inside a vault: the
 * sync `getVaultClaim` pre-check short-circuits before any async work, so the
 * 99% non-vault calls are byte-identical to the undecorated client. Only when a
 * path actually belongs to a vault do we resolve the engine and translate.
 *
 * Scope: every webdav method that carries a path or content - listFiles,
 * getFileInfo, createFolder, deleteFile, moveFiles, copyFiles,
 * restoreFileVersion, setProperties, and the content methods getFileContents /
 * putFileContents (which add a body transform, decryptContent / encryptContent,
 * on top of the path one).
 *
 * What the decorator genuinely cannot reach is anything that doesn't ride the
 * webdav client at all: signed-URL downloads (getFileUrl returns a URL, not
 * bytes), the uppy/tus upload queue, and the delete/paste/restore web workers
 * (their own client instance). Those keep their own vault handling.
 *
 * Also out of scope: getPathForFileId / listFileVersions take only a fileId
 * (no space), so the wrapper can't resolve the vault engine to decrypt the
 * returned server path. A fileId deep-link into a vault therefore resolves to
 * the encrypted path (correctness only, no leak). The proper fix is the
 * per-user vault registry that will replace `.vault`-suffix detection; until
 * then this is a known limitation.
 */
export declare function createVaultWebDav(inner: WebDAV): WebDAV;