wandering1
8b0ea17b71
现象：`ftp_test.py` 的 `LIST 150->226` 断言失败——1512 B 数据全收到了，完成回包却是 **550**。 **根因**（`send_list`/`send_nlst` 各一处）：定案三把"整份目录一次性批量发送"落进 static 1536 B 缓冲时，顺手留下了"装满就 `break` 并回 −1"，`cmd_list` 据此回 550。于是目录一旦超过一块，客户端 拿到的是**静默截断**的清单**外加一个错误码**——而清单看起来完全像"目录里就这些"。这比单纯报错 更危险：没有人会去数条目个数。 **台架实测（同一台设备、同一个根目录，改动前后各测一次）**： · 改前：1512 B / **24 条目** / 完成回包 **550**（停在 A0007.BIN，后面 6 个文件被吞） · 改后：1880 B / **30 条目** / 完成回包 **226** **修法：满块续发**，而不是把缓冲区加大。新增 `list_batch_flush()`——装满一块就整块发出、清空 继续装，收尾再发最后一块。为什么仍要"批量"：定案三的本体是实测结论——同一连接上背靠背 ~60 B 小段写会毒化 CH395F 的 TX（芯片报 SEND_OK 但对端全丢，无 RST 无 DISCONNECT），而 RETR 的 1 KB 满块连发安全；所以这里只发大块，绝不退回"每行一发"。单行真装不下时**明确失败**而不是少发条目 （8.3 短名 + 定长格式远小于 1536，真发生说明格式被改坏）。两条出口的 `lftpd_io_closedir` 收敛到 循环后单点：卷锁持有至 closedir，任何提前 return 都会漏锁。 **防回退**（关键）：修完之后，**目录清空的设备上这颗雷再也暴露不出来**，所以补了 `test/host/ftp_list_fill_test.py`——自造 26 个 8.3 短名文件把清单撑过一块，三条判据（STOR 全 226 ／LIST 全文里每个名字都在／完成回包 226 而非 550，用 ftplib `retrlines` 让非 2xx 完成直接抛）， 跑完逐个 DELE 还原。真机实测 `收到 56 行 / 3544 字节`（跨 3 块，满块续发被真正走到）→ 三条全 PASS。用法登记进 `docs/测试说明/FTP_Test_Guide.md` §4.5，机理与增补写进 `docs/问题记录/CH395F_Trap_Records.md` 定案三。 **顺带记录的已知偏差（未修）**：`cmd_list`/`cmd_nlst` 忽略命令参数、恒列会话 CWD （`client->directory`）。主流客户端都是 `CWD` + 裸 `LIST`，实际影响小，先记在案。 体量：`Code` 213,264 → **213,436 B（+172）**、RO 不变 → `ER_IROM1` **232,088 B（22.1%） **、 `ROM 合计` 233,276 B；**RAM 一字未动**（`RW_IRAM1` 75,264 B 57.4% / `RW_CCM` 57,376 B 87.9%）。 数字联动照做：`data/ram_report` 重跑、`ram_baseline --update/--write`、 `check_mem_numbers --write`、 FLASH 配图常量重算重生成（桶合计 = 232,088 与 `Code+RO` 相符）、报告 §1.3/§5.1/§5.4 与部署 §3.3。 门禁：`@build` 0 错 0 警告；`@test` PASS（692 ms）；`ftp_test.py` → **TEST PASSED**（含此前失败 的 `LIST 150->226`）；`ftp_up_dl_test.py` → TEST PASSED；`ftp_list_fill_test.py` → TEST PASSED； `doc-links --all` 146 文档 0 问题；`id-check --strict` 增量拦截通过（可判定 82.82%）； `mem-numbers` / `mem-budget` 通过；改动文件字节卫生 BOM 无 / CR 0 / U+FFFD 0 / 无行尾空格。未推送。
Drivers/BSP/NET/lftpd/ — 轻量 FTP 服务器（第三方移植）
⚠️ 第三方开源库移植（lftpd，许可证见
LICENSE.txt），非自研代码。 本目录 README 仅说明其在本项目中的定位与对接方式；库内部逻辑请参考上游。
文件一览
| 文件 | 作用 |
|---|---|
lftpd.c/h |
FTP 服务器主体（命令解析、状态机、数据通道） |
lftpd_io.c |
I/O 适配层（本项目对接 FatFs 的关键所在） |
lftpd_inet.c |
网络适配（对接本项目的 BSD Socket API） |
lftpd_log.c |
日志输出适配 |
lftpd_string.c |
字符串工具 |
private/*.h |
内部头文件 |
LICENSE.txt |
上游许可证 |
在本项目中的对接
ftpTask（App/ 侧创建）
↓ 等待 SYS_EVT_NET_READY + SYS_EVT_STORAGE_READY（osFlagsNoClear！）
lftpd（本目录）
├── lftpd_inet.c → Drivers/BSP/NET/net_socket.c（BSD Socket API）
└── lftpd_io.c → Lib/FatFs（文件读写）
⚠️ 项目相关注意
- ftpTask 就绪屏障：
osEventFlagsWait等两位就绪必须加osFlagsNoClear， 否则位被先到的消费者清掉 → FTP 21 端口静默不监听（无日志无报错） - lftpd 大局部缓冲：已按
docs/内存管理/RAM使用分析与优化方案.md§4.1.4 静态化 9 处 大局部缓冲（BSS +4.6KB），使 ftpTask 栈峰值从 3480B 降到 1184B——勿改回局部变量 - 上传中止截断：FTP STOR 中途断开后首笔复连被截断（TRAP-NET-18）已在
net_socket.c侧修复 - 本目录受 pre-commit 的部分排除（第三方代码）
相关文档
- 测试指南：
docs/测试说明/FTP_Test_Guide.md - 台架探针：
test/host/ftp_abort_probe.py、MDK-ARM/ftp_freeze_probe.py - 内存优化：
docs/内存管理/RAM使用分析与优化方案.md§4.1.4