在FTP LIST中表示未知文件大小的方法？ [英] Way to represent unknown file size in FTP LIST?
问题描述
我有一台运行在生成合成文件的设备上的FTP服务器。即文件实际上不存在于文件系统上。只要请求下载，它就会随时生成。它的大小直到它被生成时才知道。
某些FTP客户端（例如Windows资源管理器）明显使用FTP LIST命令中的信息来确定预期的文件大小，他们下载它。当我请求下载时，Windows资源管理器首先尝试FTP SIZE扩展名（ RFC 3659 ），这是服务器不支持的。然后它下载整个文件（我在Wireshark中看到了所有内容），但它将截断文件到LIST中报告的大小。
预期的是什么行为在这里？ Windows资源管理器是否采用这种优化/安全措施来执行规范？
我们目前的解决方法是显示文件大小比文件中的文件大列表。
在 ls -l </ code> / FTP LIST中有没有办法表示一个未知文件大小？当我阅读 RFC 959 时，LIST格式不是标准化的，但我猜测POSIX <一个href =http://pubs.opengroup.org/onlinepubs/9699919799/utilities/ls.html =nofollow> ls '-l'格式很常见，而且Windows资源管理器正在解析
我应该如何处理这种情况？
这里的预期行为是什么？ Windows资源管理器是否采用这种优化/安全措施在规范之外进行操作？
该规范没有说明有关检查文件大小转移大小，但如果您严格遵循规范，则不知道文件是否完全传输。您可以在客户端上获得的是数据连接已关闭，但这也可能是由于服务器端的问题。
因此，客户端正试图解决这些限制。
有没有办法在' ls -l'/ FTP LIST？在阅读RFC 959时，LIST格式不是标准化的，但我猜POSIX格式是很常见的，而且Windows资源管理器正在解析它。
是的，没有标准格式，但通常使用 ls -l </ code>的输出。由于这涉及到文件系统的静态文件都具有已知的文件大小，因此无法给出类似未知大小的文件。但是由于格式不规范，你可能会尝试简单地给出文件列表，而没有任何大小（如使用NLST）。除此之外，您的客户端仅实现FTP的典型用例，即传输静态文件。在这种情况下，文件大小是已知的。但是你以非典型的方式使用FTP，所以你必须处理这些错过的期望和欺骗。由于涉及防火墙或专用网络时FTP无论如何都是一场噩梦，所以您最好转换到其他广泛使用的协议，如HTTP或WebDAV。
I have an FTP server running on a device which generates a synthetic file. i.e. The file is not actually present on the file system. It is generated on the fly whenever it is requested for download. Its size is not known until it is generated.
Certain FTP clients (e.g. Windows Explorer) are apparently using the info from the FTP LIST command to determine the expected file size after they download it. When I request the download, Windows Explorer is first trying the FTP SIZE extension (RFC 3659), which the server doesn't support. Then it downloads the entire file (I see the whole contents in Wireshark), but it truncates the file to the size that was reported in the LIST.
What is the expected behavior here? Is Windows Explorer acting outside of spec with this optimization / safety measure?
Our current work-around is to show the file size as bigger than it will ever be in the file listing.
Is there a way to represent an unknown file size in an ls -l / FTP LIST? As I read RFC 959, the LIST format is not standardized, but I'm guessing the POSIX ls '-l' format is pretty common, and that Windows Explorer is parsing that.
How should I be handling this situation?
What is the expected behavior here? Is Windows Explorer acting outside of spec with this optimization / safety measure?
The spec does not say anything about checking the file size against the transferred size, but if you strictly follow the spec you don't know if the file was transferred fully. All you can get on the client is that the data connection closed, but this might be also because of problems on the server side. So the client is trying to work around these limits.
Is there a way to represent an unknown file size in an 'ls -l' / FTP LIST? As I read RFC 959, the LIST format is not standardized, but I'm guessing the POSIX format is pretty common, and that Windows Explorer is parsing that.
Yes, there is no standardized format, but commonly the output of ls -l is used. Since this relates to a file system with static files which all have a known file size there is no way to give something like an "unknown" size. But since the format is not standardized you might try to simply give the file list, without any size (like with NLST).
Apart from that your client just implements the typical use case for FTP, i.e. transferring static files. In this case the files sizes are known. But you are using FTP in an atypical way, so you have to deal with these missed expectations and cheat. Since FTP is a nightmare anyway when firewalls or private networks are involved you might better switch to other widely used protocols, like HTTP or WebDAV.
这篇关于在FTP LIST中表示未知文件大小的方法？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
