export declare function temporaryPathFor(filePath: string): string;
/**
 * Publish `content` atomically.
 *
 * A failed write removes its own sidecar. Leaving it behind would litter
 * the store with files that look like records to anything scanning the
 * directory, and the next attempt would not reuse it anyway.
 */
export declare function atomicWriteFile(filePath: string, content: string, options?: {
    readonly mode?: number;
}): Promise<void>;
/**
 * Publish `content` atomically AND durably: when this resolves, the new body
 * and the rename that published it are on stable storage.
 *
 * {@link atomicWriteFile} survives a process crash — a reader sees the old
 * file or the new one — but not a power loss: without an fsync the kernel may
 * not have written the new body, or the directory entry that names it, when
 * the machine stops. For a record that is about to become the ONLY thing
 * pointing at some data (the older copy of which the caller deletes next),
 * that is the difference between losing an update and losing the record.
 *
 * Costs two fsyncs, so it is for rare writes. On Windows, where a directory
 * cannot be opened for fsync, the directory entry is left to the filesystem;
 * see {@link syncDirectory}.
 */
export declare function durableWriteFile(filePath: string, content: string): Promise<void>;
/**
 * Make the entries of `directory` — a rename into it, a file created in it —
 * survive a power loss.
 *
 * A failure is thrown on POSIX: a caller that asked for durability and did not
 * get it must not go on to delete what the durable copy was meant to replace.
 * On Windows opening a directory for fsync raises `EPERM` and there is no
 * other way to ask, so there it does nothing; NTFS journals its metadata.
 */
export declare function syncDirectory(directory: string): Promise<void>;
//# sourceMappingURL=atomic-write.d.ts.map