惊天大Bug?让人呕血的FtpWebRequest

本来以为2.0开始内置了FtpWebRequest,以后不用再受没有更新保障的第三方Ftp类库的限制,结果今天遇到的问题,让我呕血三升不得其解。看来又得自己写FtpClient的类了。言归正传,先说问题

以前用到Ftp上传很多都是一次性的操作,所以如果:

FtpWebRequest req = (FtpWebRequest)FtpWebRequest.Create("url");

之 后的话就可以上传,下载,或者什么的,之后就直接退出了事。结果现在的需求会涉及很多比较具有持续性的操作,比如进入一个根目录,然后list,判断是否 存在一个目录,如果存在就cd进入,不存在就md创建这个目录,之后进入,再上传文件到目录中。这个时候麻烦产生了。一般来说为了安全性的原因,设置 FTP的时候都设置了锁定用户在主目录的选项。比如Serv-U如下:

image

这个时候第一次执行,很好,一点问题都没有,但是第二次执行的时候麻烦就来了。

比如Ftp的根url为 Ftp://xx.xx.xx.xx/ 要进入的目录为test,第一次在FtpWebRequest.Create("Ftp://xx.xx.xx.xx/");的时候,我们list得到的是根目录的内容,但是在上传完成后进行第二次操作,这个时候创建FtpWebRequest对象的url仍然是 Ftp://xx.xx.xx.xx/ 但是再执行list的时候取出的确是test目录下的文件列表!!

之后为了测试我去掉了 image 之后执行就一点问题都没有了。

但 是注意,这里的两次操作是两个不同的FtpWebRequest对象,却保持了同一个操作的Session。且让人郁闷的是,FtpWebRequest 没有提供任何显示关闭连接的方法,也没有任何改变工作目录的方法,即使是新建的FtpWebRequest对象使用了不同的url,仍然不会改变其当初的 工作目录,后来查了一下Serv-U的日志,发现根本就没法送改变工作目录的指令………

为了FtpWebRequest的对象不保持连 接的上下文,我把KeepAlive属性设为false,结果出现了第二个让我呕血的问题。当第二次执行操作的时候,报错了,如果是连本机的FTP则报返 回226 transfercomplete的异常,如果是远程的ftp则报无法访问已经释放的对象……………

不知道如此一个脑残的东西是如何通过层层审核进入.NET的类库的。呕血的FtpWebRequest

如果有兴趣的可以自己实验一下,验证一下结果,测试的case为:

while(true){

创建FtpwebRequest

列表目录

创建FtpWe

上传文件

此处打断点

}

还可以通过Serv-U看看其中的log,看看到底发送了些什么ftp指令

如果有达人发现是我哪里搞错了也请告之,万分感谢。

posted on   亚历山大同志  阅读(10632)  评论(17编辑  收藏  举报

编辑推荐:
· 如何编写易于单元测试的代码
· 10年+ .NET Coder 心语,封装的思维:从隐藏、稳定开始理解其本质意义
· .NET Core 中如何实现缓存的预热?
· 从 HTTP 原因短语缺失研究 HTTP/2 和 HTTP/3 的设计差异
· AI与.NET技术实操系列:向量存储与相似性搜索在 .NET 中的实现
阅读排行:
· 周边上新:园子的第一款马克杯温暖上架
· Open-Sora 2.0 重磅开源!
· 分享 3 个 .NET 开源的文件压缩处理库,助力快速实现文件压缩解压功能!
· Ollama——大语言模型本地部署的极速利器
· [AI/GPT/综述] AI Agent的设计模式综述

导航

< 2009年11月 >
1 2 3 4 5 6 7
8 9 10 11 12 13 14
15 16 17 18 19 20 21
22 23 24 25 26 27 28
29 30 1 2 3 4 5
6 7 8 9 10 11 12

统计

点击右上角即可分享
微信分享提示