open
https://gitlab.synchro.net/main/sbbs/-/issues/1240
`smb_t.file` (`src/smblib/smbdefs.h:676`) holds the path plus base filename of a
message or file base, and is hard-coded to 128 bytes:
```c
char file[128]; /* Path and base filename (no extension) */ ```
That is shorter than `MAX_PATH` on every platform Synchronet targets: 260 on Windows (`_MAX_PATH`), 1024 on macOS/BSD (`MAXPATHLEN`), 4096 on Linux (`PATH_MAX`). smblib itself already builds the filenames derived from this field
in `MAX_PATH + 1` buffers (`smblib.c:1521`, `smblib.c:2115`, where it appends `.shd` / `.sdt` / `.sid` / `.sda` / `.sha` / `.sch` / `.ini` / `.hash`), so the struct field is the only undersized link in the chain.
## How it truncates
Roughly 52 sites across the tree populate the field, all of them with a bounded printf, for example:
```c
SAFEPRINTF(smb->file, "%smail", cfg->data_dir); // load_cfg.c:661
SAFEPRINTF2(smb->file, "%s%s", cfg->sub[subnum]->data_dir, cfg->sub[subnum]->code); // load_cfg.c:667
```
The 127-character bound is exceeded by the configured field widths alone, and has been for a long time:
- `sub_t.data_dir` and `dir_t.data_dir` are `LEN_DIR + 1` (101), and `sub_t.code`
/ `dir_t.code` are `LEN_EXTCODE + 1` (33). A sub-board or directory with a
per-area data directory can therefore produce up to 132 characters.
- `cfg.data_dir` is `LEN_SYSDIR + 1`, capped at `MAX_PATH` as of 2cd36a8803
(printing-38-wait, 2026-09-11), so `"%smail"` can reach `MAX_PATH + 4`.
Because every site uses a bounded printf, the truncation is silent: no `last_error`, no log line, no non-zero return.
## Consequence
`smb_open()` then operates on the truncated name. Either it fails with an ENOENT
naming a path the sysop never configured, which is hard to recognize as a length
problem, or, if two configured bases share their first 127 characters, both resolve to the same `.shd` / `.sdt` pair and one silently reads and writes the other's data.
## Suggested fix
Size the field `MAX_PATH + 1`, matching the buffers smblib already uses for the filenames it derives from it.
`smb_t` is a runtime structure and is never serialized (nothing writes the struct
itself to disk), so this is not an on-disk format change. It does change `sizeof(smb_t)`, so every consumer has to be rebuilt together: sbbs.dll / libsbbs.so, the servers, smbutil, chksmb, fixsmb and sbbsecho. The Borland-built
sbbsctrl.exe and UserEdit.exe do not reference smblib and are unaffected.
## How this surfaced
While fixing the GCC `-Wformat-overflow` warnings that followed the wider `scfg_t` directory fields, one of the 31 sites was sbbsecho's `export_netmail()`,
which built this path with a bare `sprintf()`. It was changed to `SAFEPRINTF()` at 3d5feda5b2 (cord-3-waiver, 2026-09-11) to match its peers. That silenced the diagnostic but not the truncation, which is what this issue tracks.
-- *Authored by Claude (Claude Code), on behalf of @rswindell*
--- SBBSecho 3.37-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)