Subj : docs/v322_new.md exec/inventory_archives.js exec/load/filecontents_lib
To   : Git commit to main/sbbs/master
From : Rob Swindell (on Debian Linux)
Date : Mon Sep 21 2026 22:21:21

https://gitlab.synchro.net/main/sbbs/-/commit/d9669612528f11e627aa00e9
Modified Files:
	docs/v322_new.md exec/inventory_archives.js exec/load/filecontents_lib.js exec/tests/filecontents_test.js
Log Message:
filecontents: keep the listing in the file record's own auxdata

A per-area data/dirs/<code>.contents file meant that serving one listing
parsed a single JSON object holding every listing in the area.  Measured
on the largest area here, one view read 4.78 MB and spent 31 ms and
34.8 MB of RSS to return 1 record out of 76, and a cold view
re-serialized the whole file to add one.  That heap is the same
mozjs185 pressure the stored listings exist to avoid.

In auxdata the cost is the record's own data blocks: the same 295 KB
listing reads in 2 ms and 1.6 MB, a typical record in no measurable time
or heap, and neither depends on how many archives the area holds.  The
listing is also removed with the file record, so nothing is left behind
when a file goes away, and there is no second file, lock or orphan sweep
to maintain.

The listing goes under an "archive_contents" key rather than owning the
slot, and auxdata that this library did not write, or cannot parse, is
left alone instead of replaced.  put() hands the description and
extended description back with every write, so a record survives a build
whose FileBase.update() drops the text it was not given or refuses an
object carrying only auxdata.

inventory_archives.js loses its batched merge and its lock: each record
is now written on its own.

The record carries the format version the store file's wrapper used to
hold, in place of a type field that named what the key already says and
that nothing read.  A record written in an encoding this code does not
know now reads as absent and is extracted again, rather than being
parsed on the assumption that it matches.

No migration is needed: a missing record is extracted and stored on
first view, so the base warms itself.  The data/dirs/*.contents files
from the previous arrangement are simply unused.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
--- SBBSecho 3.37-Linux
 * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

.