FTP Improvement

[Dave_Thomson]

I would like to suggest that NI add some needed functionality to the FTP VI's that it ships with. As  you can see in this thread: http://forums.ni.com/t5/LabVIEW/Access-FTP-with-whitespaces-in-dir-names/m-p/3097215#M886371  the FTP LIST command does not work well for some FTP servers when the directory being listed has spaces in its name. The FTP MLSD command does work in this case, but there are other servers which don't support MLSD. My post on the above thread implements a fairly crude mechanism for using whichever command does work. But more importantly, the MLSD isn't even included in the NI FTP library. It would be great if the NI FTP VIs worked over a broader range of FTP servers.

[rolfk]

The problem with this proposal is likely that FTP is inherently unsafe and NI is trying everything to get away from it. That combined with the fact that FTP is a simple string based protocol that anyone can implement or extend an existing library of functions with anything they feel a fancy for, makes it prettty unlikely that the FTP library is going to be reworked to support more commands. More likely the more people moan about it, the bigger is the chance that NI declares its own library as fully unsupported and will eventually pull it entirely from their servers.

[nanocyte]

What's unsafe about it? The fact that everything is sent in the clear? That's not a problem for many embedded closed network situations.

[rolfk]

The fact that everything is sent in clear text is one of the problems. There are a few others such as that most FTP implementations have known security vulnerabilities. The intend may be to use those hardware devices only on a fully isolated network but in reality they often happen to get at least indirectly connected to the greater business network and even the whole internet.

[Dave_Thomson]

It IS clear that NI is moving away from FTP, which I whole-heartedly agree with. That is, NI is working on getting cRIO and other NI platforms to use better file transfer methods by default. However, that is completely different than removing FTP support from LabVIEW. LabVIEW is inherently open. As LabVIEW developers, we're interfacing to a wide range of devices in an immense universe of situations. Regardless of its limitations, FTP is still out there, and LabVIEW needs to support it.

15 years ago, everyone was saying that the async serial port had died, and that USB would be taking over. Luckily, VISA still supports RS232 serial, because the reality is that it still exists in our applications.

Having sub-par FTP VI's doesn't do anyone any good. Improving the FTP VI's may not make it to the top of NI's priorities, but it is still a worthwhile endeavor.