为何 SftpPersistentAcceptOnceFileListFilter 使用 longFilename？

2026-11-04数据小许

结论

如果 Spring Integration 7.0.x 中该过滤器确实使用 SftpClient.DirEntry.longFilename 生成持久化键，那么当前记录就与文档所说的“目录路径加简单文件名”不一致。longFilename 通常是用于展示的长格式目录项文本，示例中的权限、用户、大小和日期都属于展示信息。持久化键中的文件名应是 FILENAME.txt 这样的简单文件名，并与目录路径组合。

仅凭问题中的记录，无法判断这是有意的兼容性调整还是实现缺陷，也无法确认具体改动原因。需要检查你使用的 7.0.x 补丁版本源码或变更记录。

核对过滤器实际使用的字段

SftpClient.DirEntry 中，文件名和长格式文本是两个不同的字段：

String simpleName = entry.getFilename();
String displayText = entry.getLongFilename();

对于示例文件，文件名部分预期应为 FILENAME.txt。下面这段是长格式目录项文本：

-rwxrwxrwx 1 1000 1000 346 Mar 11 2026 FILENAME.txt

调试时可以分别记录这两个值，再检查 SftpPersistentAcceptOnceFileListFilter 构造持久化键时使用了哪个字段。包含目录列表信息的键不要直接当作文件名使用。

建议的排查步骤

确认实际运行的 Spring Integration 版本和补丁版本，避免检查到与运行依赖不一致的源码。
查看该版本过滤器的 fileName 实现，确认它是否返回 getLongFilename()；同时检查调用方如何组合目录路径、前缀和文件名。
对照文档核实预期的键：先组合目录路径（若适用）和简单文件名，再按该过滤器的规则添加前缀。对于没有额外目录部分的示例，文件名部分应为 FILENAME.txt。
如果实现确实使用长格式文本，且没有对应的设计说明，可以通过兼容性测试验证升级或修复方案，再向 Spring Integration 项目提交问题，并附上版本、最小复现和实际键值。

如果需要临时规避，可以使用基于 entry.getFilename() 生成键的自定义过滤器，或修正现有实现。具体扩展方式取决于该版本过滤器提供的可扩展接口。更换前缀未必能解决问题，因为示例中的异常内容来自长格式目录项。