Filesystem on WebAssembly¶
Include: Use System\FileSystem.pkg
The WebAssembly (WASM) runtime exposes the same Filesystem commands as the native runtimes, but files live in the browser tab instead of on disk. Where a file is written determines whether it survives a page reload.
In-memory by default¶
Outside of /dev/idbfs, the filesystem is held entirely in the browser tab's memory. A file written to, for example, /data/cache.txt exists only for the current page session — reloading or closing the tab discards it, along with anything else written outside /dev/idbfs.
Persistent storage under /dev/idbfs¶
/dev/idbfs is backed by the browser's IndexedDB storage, so it survives a page reload. Files written there are picked up automatically and persisted to IndexedDB in the background as they change — no separate save or flush step is needed. On the next load, in the same browser and origin, the previously written files are there again.
Use /dev/idbfs for anything that needs to outlive the current page session — application settings, cached data, a SQLite database, or documents a user creates. Use any other path for scratch or temporary files that only need to exist for the current session.
Example¶
Handle hFile
Get Seq_New_Channel to hFile
Direct_Output Channel hFile "/dev/idbfs/settings.ini"
Write_Line Channel hFile "LastRun=2026-08-31"
Close_Output Channel hFile
Send Seq_Release_Channel hFile
/dev/idbfs/settings.ini is still there after a page reload. The same file written to /settings.ini instead would be gone as soon as the page reloads.
A cDbSqliteDriver connection string follows the same rule — sqlite:/dev/idbfs/MyAppData.db?mode=rwc keeps the database across reloads, while a bare sqlite:MyAppData.db does not.
Paths and separators¶
The WASM runtime uses / as the directory separator and ; as the path separator, the same separator DF_OPEN_PATH uses; see DFPATH.