我在设备上运行FTP服务器,生成合成文件。即文件实际上不存在于文件系统中。无论何时请求下载,它都会立即生成。它的大小在生成之前是未知的。
某些FTP客户端(例如Windows资源管理器)显然正在使用FTP LIST命令中的信息来确定下载后的预期文件大小。当我请求下载时,Windows资源管理器首先尝试FTP SIZE扩展({{3}}),服务器不支持。然后它下载整个文件(我在Wireshark中看到了全部内容),但它将文件截断为LIST中报告的大小。
这里的预期行为是什么? Windows资源管理器是否采用此优化/安全措施来执行规范?
我们目前的解决方法是将文件大小显示为文件列表中的文件大小。
有没有办法在ls -l
/ FTP LIST中表示未知文件大小?当我阅读RFC 3659时,LIST格式没有标准化,但我猜测POSIX RFC 959' - ''格式很常见,并且Windows资源管理器正在解析它。
我应该如何处理这种情况?
答案 0 :(得分:1)
这里的预期行为是什么? Windows资源管理器是否采用此优化/安全措施来执行规范?
规范没有说明根据传输的大小检查文件大小,但如果您严格遵循规范,则不知道文件是否已完全传输。您可以在客户端上获得的只是数据连接已关闭,但这也可能是因为服务器端存在问题。 所以客户正试图解决这些限制。
有没有办法在'ls -l'/ FTP LIST中表示未知文件大小?当我阅读RFC 959时,LIST格式没有标准化,但我猜测POSIX格式很常见,并且Windows资源管理器正在解析它。
是的,没有标准化格式,但通常使用ls -l
的输出。由于这涉及具有静态文件的文件系统,这些文件都具有已知的文件大小,因此无法给出类似“未知”大小的内容。但由于格式没有标准化,您可能会尝试简单地给出文件列表,没有任何大小(如NLST)。
除此之外,您的客户端只是实现了FTP的典型用例,即传输静态文件。在这种情况下,文件大小是已知的。但是你以非典型的方式使用FTP,所以你必须处理这些错过的期望并作弊。由于FTP涉及防火墙或专用网络时无论如何都是一场噩梦,因此最好切换到其他广泛使用的协议,如HTTP或WebDAV。
答案 1 :(得分:0)
客户端的解决方法可能是使用wget或'ftp'命令。 'ftp'命令示例:
因为wget和'ftp get command'都不需要大小来下载文件。
另一个解决方案可能是使用自己的ftp服务器。您可以找到许多具有基本功能的服务器,gui客户端支持和脚本语言的简单代码,如php。更改此功能的代码很简单。我为其中一个项目做了同样的事情。