10-04-2016 10:11 AM
Thanks, peper. I should have thought of that! Should be easy enough to implement. I'll work on getting something going.
As I said, I'll try to convince NI to update their shipping code. To do that, someone will have to figure out if either 1) MLSD is an improvement over LIST for all or almost all FTP servers, or 2) add extra logic to use one of them, then if the result is an empty listing, use the other. This link https://www.flashfxp.com/forum/flashfxp/frequently-asked-questions-faq-/13575-list-list-al-mlsd-stat... indicates that MLSD should be an acceptable replacement to LIST, as long as you don't need to see hidden files.
Have you ever found an FTP server that works with LIST but DIDN'T work with MLSD?
Cheers,
DaveT
10-05-2016 01:22 PM
I've created a work-around. It has its limitations. It's definitely not as polished as the NI FTP VI's. It doesn't handle all the errors completely. It doesn't handle "link" directory entries. But so far, it has served my purposes. I've based it on the screen shot peper posted as well as the existing NI FTP VIs.The way I've packaged it, it tries the MLSD command first. Some servers don't know that command and will return an error. If it works, it just parses that result. If it doesn't work, it remembers that and then it uses the LIST command. I send the memory of the MLSD failure out so that you can wrap it around in your calling program. E.g. it should be cleared whenever the FTP connection is closed, in case the next connection handles these commands differently. But by wrapping it around, once the MLSD command fails, it won't waste time trying it for every directory listing. However, if you don't wrap it around, things will still work. It will just keep trying MLSD before using LIST.
This could use a lot of cleaning up and testing on different FTP servers before an official release, but hopefully NI will consider doing that.
Regards,
DaveT
10-06-2016 05:14 AM - edited 10-06-2016 05:17 AM
You could cache the refnum and the status of the MLSD query in an uninitialized shift register (LV2 style global) and compare that refnum with the currently passed in refnum. If it matches, use the cached status to determine if you should attempt to call the MLSD function, otherwise always try the MLSD first. Not 100% optimal if you ever happen to have two parallel FTP connections but I would think good enough for 99.9% of the use cases.
And if you use FTP in a place where you repeatedly and often have to query the remote directory, then you might have likely much bigger problems than a little performance loss.