Session files on your computer

DataMind Oda saves every chat as a session log file on your computer as you work. This page shows where those files live, how Oda keeps them from being half-written or overwritten, and what the cached details in the chat list mean. Copying the files or reading a log yourself is covered in Chat logs on disk.

Where the files live

Oda keeps every chat under one folder on the computer; this page calls it the log folder.

• The log folder is set when Oda is set up on the computer. It has no default, and Oda creates it when it first needs it.
• Inside it, chats are grouped by the folder they work in. A group's folder is named after that working folder, wrapped in --.
• A chat that has no working folder yet sits in a group named _no-cwd.
• Each chat has a folder of its own, and its name is built from the chat's id, encoded so the id is safe as a folder name.

<log folder>/
  --<working folder>--/
    <chat folder>/
      session.jsonl.zstd
      session.v4.jsonl.zstd

• A chat reaches the disk only when it first has content: files appear on its first save, not when the chat is created. A chat you never used leaves no files, even if Oda stops suddenly.

How log files are named and kept

• The oldest log format keeps the plain name session.jsonl. Later formats add their version to the name, as in session.v4.jsonl.
• Compression is on by default, and a compressed log's name ends in .zstd. With compression off, a log is plain text: one JSON object per line.
• A log folder keeps one form, all compressed or all plain; Oda refuses a file whose form does not match its folder instead of guessing.
• Oda reads only files with these exact names. A renamed copy, such as session.v1.backup.jsonl, is not treated as a log.
• When Oda updates a log written by an older format, the new file is added beside the old one; Opening sessions from other versions covers that conversion. The source stays exactly as it was, and the newest file is the chat's current state.
• Nothing removes session files for you: Oda has no action that deletes a chat's log or trims its older files, so they stay until someone removes them.
• Listing the chats under the log folder takes longer as the folder stores more of them.

One writer at a time

Each chat's log has one writer at a time, so two copies of Oda cannot write into the same chat at once.

• The rule covers every copy of Oda on the computer, not only one window. While the first writer is alive, a second is refused; reading the chat is not blocked.
• A copy of Oda that is still alive keeps the lock until that copy stops; Oda has no timeout that takes it away.
• The lock ends with the program that holds it, so a crash leaves no stuck lock and the chat can be opened for writing again right away.
• On some systems the lock shows as a small file named session.lock in the chat's folder. If a chat stays locked because the copy of Oda holding it cannot continue, removing that file frees the chat for the next writer; do this only when you are sure that copy will not write the chat again.

What a completed save means

• A save counts once it has completed: everything Oda has saved is kept, even if a stop comes later.
• Once a save has completed, Oda never falls back to an older state of the chat.
• A chat becomes visible to other copies of Oda only after its first save has reached the disk.
• A sudden stop can leave an unfinished piece at the end of a log; Recovering sessions after a crash covers what Oda does when you next open the chat.

Cached details in the chat list

The chat list can serve a chat's details without reading its whole log. When it serves them from a saved checkpoint, it labels the block cached.

• Checkpoints are written when a chat is created, at the end of each turn, and when the chat closes, with steady updates in between.
• Cached values can be as old as the last checkpoint, but they are never wrong: a value that does not fit the chat's log is discarded, and the values are rebuilt from the log.
• A chat's log always leads its cached values: if a checkpoint write fails, the cache stays behind until the next save catches it up, and after a crash the cache can be behind, never ahead.
• If a cache file cannot be read, Oda sets it aside and rebuilds the values from the log; your chat is not affected.

When a log cannot be used

Oda refuses to work from a log it cannot read rather than guess, and it leaves the file as it is. The message names the reason and, for many of these cases, the file itself as a raw log: <path> note. For the messages you may meet and what to do about each, see Session log problems.

Questions, answered

Where does Oda keep my chats on this computer?

All chats live under one folder, the log folder, which is set when Oda is set up on the computer; it has no default. Inside it, chats are grouped by the folder they work in, and every chat has a folder of its own. If you do not know which folder was chosen for this computer, ask your DataMind OS administrator.

Why is there no file for a chat I have not used yet?

A chat reaches the disk only when it first has content. Until then it lives only in Oda, and a chat you never used leaves no files at all, even if Oda stops suddenly. Working in the chat creates its folder and its first log file.

What do the file names mean?

session.jsonl is the oldest log format; later formats add their version, as in session.v4.jsonl. With the default compression, the name ends in .zstd; with compression off, the file is plain text, one JSON object per line. A folder keeps one form, so it holds either compressed logs or plain ones.

Why can one chat have several files side by side?

When Oda updates a log written by an older format, the new file is added beside the old one, so a chat can have several generations side by side. The newest file is the chat's current state, and the older files stay exactly as they were: Oda never renames, replaces or deletes them.

Can two copies of Oda work on the same chat?

Oda allows one writer per chat at a time, so while the copy that holds a chat is saving to it, a second writer is refused with session "<id>" is already owned by an active write handle. Reading the chat is never blocked, so you can view it in two places; the lock ends with its program, so closing the copy that holds the chat frees it for writing.

What does the cached label in the chat list mean?

The chat list can serve a chat's saved details from a checkpoint instead of reading its whole log; when it does, the block is labelled cached. Cached values can be as old as the last checkpoint, but they are never wrong: a value that does not fit the log is discarded and rebuilt from the log. A chat's log always leads its cached values, so after a crash the cache can be behind, never ahead.

Can I move a chat's files somewhere else?

You can copy the log folder to keep a backup; Chat logs on disk covers that. Keep the folder shape and the saved form when files come back, because Oda refuses a log that sits in the wrong place or the wrong form. If the same chat appears in two places under the log folder, Oda refuses to choose between the copies.

I moved my chat files. Why did the details rebuild in the chat list?

The cache binds a chat's details to its identity: its id, when it was created, the folder it works in, and whether it continues another chat. When a chat no longer matches its cached record, for example after its working folder changed, Oda rebuilds the details from the chat's log. Nothing in the chat itself is lost.