FTP传输中断后文件锁死几分钟不能访问，多半是服务端会话超时在释放

用 FTP 往服务器传文件，传到一半意外断掉，这时去服务器上看：那个只传了一半的文件点不开、删不掉，提示被占用。等上几分钟，没做任何操作，它自己又能访问了。这个「卡几分钟自己好」的现象很多人碰到过，它不是服务器坏了，而是 FTP 服务端的会话清理机制在按自己的节奏工作。

文件被谁锁着，为什么会自己松开

传输进行时，服务端的 FTP 服务进程握着这个文件的写句柄。传输意外中断时，客户端那一端可能已经消失，但服务端并不会立刻认定会话死亡——它要等自己的会话超时和清理周期走完，才把连接、会话连同文件句柄一并释放。所以那几分钟空窗，就是服务端在等超时；原帖里「约六七分钟不可访问」的观察，对应的正是那台服务器当时的清理周期。不同 FTP 服务端软件的默认值不一样，有的几十秒，有的几分钟，但「中断后锁一小段时间、到点自动释放」这个行为模式是一致的。

传输为什么中断：三个来源分清

一是链路抖动，网络瞬断或质量差，连接被掐掉；二是客户端异常退出，断网、进程被杀、用户直接关了窗口，都会留下一个服务端还以为活着的会话；三是服务端主动超时，传输太慢或控制连接长时间没有动作，服务端按策略把会话踢掉。想分清是哪一种，去翻服务端的 FTP 日志，会话结束的原因（超时、复位、正常退出）一般都有记录——盲猜不如看日志。

断点续传不是默认就有的

传了一半断了，能不能从断点接着传而不是从头再来？这要看两端的支持：服务端要支持在写入前用命令定位到文件的某个偏移量（FTP 协议里的 REST 命令就是这个用途，个别服务端默认禁用它对上传的支持），客户端也要用支持续传的模式去发起。两头都支持，才谈得上断点续传；有一头不支持，重新上传就是唯一的路。所以大文件走 FTP 之前，先确认续传这条后路通不通，比中断之后现想办法从容得多。

实务上的三条建议

第一，传输中断后别急着去服务器上删那个锁着的文件，先等一个清理周期，抢在句柄释放前强删往往徒劳还添乱。第二，传完之后做一次校验——比对文件大小，讲究一点的算一次哈希，确认完整再删源文件。第三，经常性大文件传输的环境，把链路稳定性和服务端超时参数一起审视一遍：中断频繁的根子多半在网络质量，不在 FTP 本身。

企业存储选型参考｜贵州诚鑫致达

做核心业务 SAN 存储与高可靠应用，群晖机型参考：UC3400 · UC3200 · SA3600。需要选型建议或上门评估，搜「诚鑫致达」即可找到我们。