再谈FTP API与总结

龙哥说日本人很强，是把每一个很平凡的东西都精益求精，所以树立了一个又一个的品牌。

所以我觉得用一本书的名字作为今年的总结 ：细节决定成败

最近测试FTP API，重新研究了一下大部分的基于JAVA的FTP CLIENT API，

发现用来取文件夹的文件列表，大部分API都是使用FTP LIST(EDT支持LIST与NLIST)命令来处理的，
但这样处理会有一个隐藏的较深的漏洞：丢失文件真实的年记录信息

用个小例子测试下：
在WINDOWS 平台上：
ftp> dir
200 PORT Command successful.
150 Opening ASCII mode data connection for /bin/ls.
drw-rw-rw-   1 user     group           0 Feb 11 21:49 .
drw-rw-rw-   1 user     group           0 Feb 11 21:49 ..
-rw-rw-rw-   1 user     group         627 Dec 17 21:13 CN_MT1201_1p0_29107265969
7492009113002303128733.mft
226 Transfer complete. 225 bytes transferred. 0.22 KB/sec.

发现LIST 返回的行的是没有文件的日期的年的部分的。
所以我觉得以此为解析得到的文件修改日期，只有月，日，天，小时，分　是对的的，其他的都是忽悠人的。
是不是和平台有关呢？
再在LINUX上测试下：

kdyi@seedwill:~$ ftp 192.168.1.100
Connected to 192.168.1.100.
220 Serv-U FTP Server v9.1 ready...
Name (192.168.1.100:kdyi): houston
331 User name okay, need password.
Password:
230 User logged in, proceed.
Remote system type is UNIX.
Using binary mode to transfer files.
ftp> dir
200 PORT Command successful.
150 Opening ASCII mode data connection for /bin/ls.
drw-rw-rw-   1 user     group           0 Feb 11 21:49 MftRecv
drw-rw-rw-   1 user     group           0 Feb 11 21:25 MftRecvBak
drw-rw-rw-   1 user     group           0 Feb 11 11:02 MftSend
drw-rw-rw-   1 user     group           0 Dec 21 12:03 MftSendBak
drw-rw-rw-   1 user     group           0 Dec 31 17:03 TraRecv
drw-rw-rw-   1 user     group           0 Dec 31 21:29 TraRecvBak
drw-rw-rw-   1 user     group           0 Dec 31 21:29 TraSend
drw-rw-rw-   1 user     group           0 Dec 21 12:03 TraSendBak
226 Transfer complete. 524 bytes transferred. 31.98 KB/sec.

发现同样是缺失文件日期的年的部分。

而且有一个还有个问题，文件日期只精确到分。

我们的应用是需要得到一个比较精确的文件时间的，用以自动排序或备份等
所以需要另外一个FTP的增强指令MLSD，可以返回一些较详细的文件信息
如:
Type=cdir;Modify=20100211081006.123; .
Type=file;Size=637;Modify=20091217131312.304; CN_MT1101_1p0_290414869054692009121604018905746.mft
Type=dir;Modify=20100211080944.109; test_dir
可以看到，其实时间可以精确到毫秒，另外就是需要注意文件名的部分前面会有个空格，需要在处理的时候注意。


到这里，我们可以扩展我们的FTP CLIENT API，比如我用的FTP4J，就需要扩展FTPClient与相应的parser.

剩下的问题就比较容易了。

如果不是刚好赶到跨年测试，也绝没有想到，FTP的API还有这么一个BUG(或者说缺陷)
因为我用了一个2009的文件作测试，却发现FTP API获取的文件时间成为了2010年的了，而且月，日，天，小时，分是对的。
所以，边界是容易发现 BUG的，就像数学中的极限容易发现问题的本质。