open https://gitlab.synchro.net/main/sbbs/-/issues/1132

The duplicate file checking/processing can take a long time after uploading. Some ideas:
```
<Deuce> Hopefully it does a parallel dupe search. :D
<Deuce> ... it does not. :(
<Deuce> Would be nice if it mentioned the filename it was processing at the start rather than at the end too.
```
--- SBBSecho 3.37-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

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

Addressed in ce3b73460e (disorder-17-goal, 2026-09-30) and be73f102c9 (twin-17-combat, 2026-09-30).

The cost was structural: for every uploaded file, the duplicate scan opened and read every dupe-checked directory's file index, so a batch of N files made N passes over every index (1,312 directories and about 22 MB of index on Vertrauen, with each open a round trip when the data lives on a file server).

- New duplicate-check cache (`dupe_cache_*` in `filedat.c`): each directory's file sizes and hash values are read from its index the first time it is consulted and kept for the life of the batch; files added during the batch are recorded so a later file in the same batch is checked against them. A single-file upload is unchanged.
- The file being processed is now named before its upload testers, hashing and duplicate scan begin (new `ProcessingUploadedFile` text string, using `@FILE_NAME@`).
- Not parallel: with each index read once per batch there is nothing left worth threading.

Verified on a scratch install: a file with the same content as an earlier one in the same batch, and one matching a file from a previous batch, were both reported as already uploaded; strace showed the duplicate scan opening each directory's index once per batch instead of once per file.

Still per file: the blind-upload path's name search, which reads every index once per file before the hash scan. Folding it into the cached pass is the remaining piece.

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

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)

close https://gitlab.synchro.net/main/sbbs/-/work_items/1132
--- SBBSecho 3.38-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)