Liking cljdoc? Tell your friends :D

konserve.node-filestore


check-and-create-backing-storecljs

(check-and-create-backing-store base)

Helper Function to Check if Base is not writable

Helper Function to Check if Base is not writable
sourceraw docstring

check-and-create-backing-store-asynccljs

(check-and-create-backing-store-async base)

Helper Function to Check if Base is not writable

Helper Function to Check if Base is not writable
sourceraw docstring

connect-fs-storecljs

(connect-fs-store
  path
  &
  {:keys [detect-old-file-schema? ephemeral? config]
   :or {detect-old-file-schema? false
        ephemeral? (fn [pathstr]
                       (some (fn* [p1__55887#] (re-matches p1__55887# pathstr))
                             [#"\.nfs.*"]))}
   :as params})

Create Filestore in given path. Optional serializer, read-handlers, write-handlers, buffer-size and config (for fsync) can be changed.

  • the k/bget callback gets different args depending on :sync?
    • async bget callbacks recieve {:input-stream <fs.readStream>} akin to the same call on the JVM filestore impl. These streams are opened to the same fd that konserve is managing for the blob, so users should not call destroy() or it will raise an error
    • sync bget callbacks are called with {:blob <js/Buffer>}

{:base path :serializer fressian-serializer :read-handlers empty :write-handlers empty :buffer-size 1 MB :config config}

Create Filestore in given path.
Optional serializer, read-handlers, write-handlers, buffer-size and config (for fsync) can be changed.

+ the `k/bget` callback gets different args depending on `:sync?`
  - async bget callbacks recieve `{:input-stream <fs.readStream>}` akin to
    the same call on the JVM filestore impl. These streams are opened to the
    same fd that konserve is managing for the blob, so users should not call
    destroy() or it will raise an error
  - sync bget callbacks are called with `{:blob <js/Buffer>}`

{:base           path
 :serializer     fressian-serializer
 :read-handlers  empty
 :write-handlers empty
 :buffer-size    1 MB
 :config         config} 
sourceraw docstring

count-konserve-keyscljs

(count-konserve-keys dir)

Counts konserve files in the directory.

Counts konserve files in the directory.
sourceraw docstring

delete-storecljs

(delete-store base)

Permanently deletes the base of the store with all files.

Permanently deletes the base of the store with all files.
sourceraw docstring

delete-store-asynccljs

(delete-store-async base)

Permanently deletes the base of the store with all files.

Returns nil on success and the error on failure — the same contract as the sync delete-store above.

Two bugs lived here, both hidden because -delete-store :file only ever called the SYNC variant until the store multimethod was taught to honour :sync?:

  1. iofs/arm-r yields [?err] — a vector (see its docstring) — not a bare err. Binding it as ?err made the success value [nil], which is truthy, so this ALWAYS took the error branch: it returned [nil] as if it were an error, and sync-base-async was never called — the parent directory was never fsynced. Sibling helpers here already destructure it correctly (_lock-async).
  2. It fsynced base — the directory arm-r had just deleted — where the sync twin correctly fsyncs the PARENT (that is the point: you fsync the parent after removing a child). Opening the deleted dir failed, and sync-base-async then called .force on the resulting Error.
  3. Even on the intended path it piped sync-base-async's value straight through instead of normalising to nil like the sync twin does.
Permanently deletes the base of the store with all files.

Returns nil on success and the error on failure — the same contract as the sync
`delete-store` above.

Two bugs lived here, both hidden because `-delete-store :file` only ever called the
SYNC variant until the store multimethod was taught to honour `:sync?`:

1. `iofs/arm-r` yields **`[?err]`** — a vector (see its docstring) — not a bare err.
   Binding it as `?err` made the success value `[nil]`, which is truthy, so this
   ALWAYS took the error branch: it returned `[nil]` as if it were an error, and
   `sync-base-async` was never called — the parent directory was never fsynced.
   Sibling helpers here already destructure it correctly (`_lock-async`).
2. It fsynced `base` — the directory `arm-r` had just deleted — where the sync twin
   correctly fsyncs the PARENT (that is the point: you fsync the parent after
   removing a child). Opening the deleted dir failed, and `sync-base-async` then
   called `.force` on the resulting Error.
3. Even on the intended path it piped `sync-base-async`'s value straight through
   instead of normalising to nil like the sync twin does.
sourceraw docstring

detect-old-file-schemacljs

(detect-old-file-schema & _args)
source

fscljs

source

list-filescljs

(list-files directory)
(list-files directory ephemeral?)

Lists all files on the first level of a directory.

Lists all files on the first level of a directory.
sourceraw docstring

list-files-asynccljs

(list-files-async directory)
(list-files-async directory ephemeral?)
source

open-async-file-channelcljs

(open-async-file-channel path)
(open-async-file-channel path {flags :flags})
source

open-file-channelcljs

(open-file-channel path)
(open-file-channel path {flags :flags})
source

pathcljs

source

store-exists?cljs

(store-exists? base)

Check if underlying store already exists.

Check if underlying store already exists.
sourceraw docstring

streamcljs

source

verify-read-sizecljs

(verify-read-size expected actual)
source

verify-write-sizecljs

(verify-write-size expected actual)
source

cljdoc builds & hosts documentation for Clojure/Script libraries

Keyboard shortcuts
Ctrl+kJump to recent docs
Move to previous article
Move to next article
Ctrl+/Jump to the search field
× close