Subj : Post-processing of batch uploads can be slow
To   : GitLab note in main/sbbs
From : Rob Swindell
Date : Wed Sep 30 2026 16:59:48

https://gitlab.synchro.net/main/sbbs/-/work_items/1132#note_10569

The remaining piece is done in 7f7405edb9 (roll-4-story, 2026-09-30): the blind-upload path's name search now reads from the batch cache too.

Each cached record carries a 32-bit FNV-1a (`fnv1a32_str()`) of the index name folded to lower case, since the question is whether the name exists in any case. A hash hit is confirmed by reading that one directory's index, so a collision costs an index read rather than a wrong "already online" verdict. With that, both passes read each directory's index once per batch: across three batch uploads under strace, every other directory's index was opened twice in total where it had been opened once per file per pass.

Why 32 bits and not 64: the cache compares within one directory, and a read-only analysis of this system's live indexes (147,462 records, 90,120 distinct lower-cased names, largest directory 12,190 records) found zero 32-bit collisions within any directory and two base-wide pairs (`focs94.zip`/`ra-pack1.zip`, `focs92.zip`/`ra-pack7.zip`), which is what an ideal 32-bit hash predicts for that many keys (0.95 expected pairs). No directory holds two names differing only in case.

`fnv1a.c` was added to the MSVC smblib project alongside the other hash sources; the Windows build is not verified from here.

-- *Authored by Claude (Claude Code), on behalf of @rswindell*
--- SBBSecho 3.38-Linux
 * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

.