This project is read-only.

Possible bug: MLSD/MLST confusion?

Mar 27, 2013 at 5:19 AM
Hi there,

I might be wrong here, but...

(Apologies if this has already been discussed, but I searched and couldn't see anything similar)

I am using version of the FtpClient.

The server I am connecting sends a response to the FEAT command, which includes a line

The presence of "MLST" in this particular line appears to confuse the GetFeatures(...) method in FtpClient.cs, insofar as it causes the FtpCapability.MLSD to be set (note, MLS_D_, not MLST). Later on this causes GetListing(...) to use the MLSD command, which my server doesn't support (resulting in a "Command not understood" message - sorry I didn't write it down...)

First, I'm not too sure if MLST capability and MLSD capability are the same thing? (referring to To be safe, I added a new FtpCapability.MLST(=1024) to the enumeration, and modified the GetFeatures(...) method to distinguish between MLSD and MLST.

Second, I'm not too sure what my server is trying to tell me with that particular response, but it seems to me that this particular line should not be interpreted to mean that MLST is supported. There is no further mention of MLST or MLSD in the response that I am dealing with.

For my own purposes, the problem is resolved with the above two changes, but I just thought I'd throw this out there in case anyone else has encountered the same issues.

Let me know if I can provide further info or if I'm way off track.

(Thanks for the great library, by the way!)

Cheers - Andrew
Mar 27, 2013 at 1:36 PM
I've never seen a server that didn't have one without the other. Since this was listed as an option, try this code before your file listing to see if it clears the problem up:
FtpReply reply;

if(!(reply = ftpClient.Execute("OPTS MLST ON")).Success) {
    // look at reply.Message to see why it failed

// get file listing as usual
Mar 27, 2013 at 1:39 PM
Also, if you don't mind include the complete response from the FEAT command.
Mar 27, 2013 at 1:44 PM
It seems that OPTS MLST is used for manually specifying facts that the MLS* commands should return. Strange problem, what server software are you using as well?
Mar 27, 2013 at 1:55 PM
All the same, this is a bug in System.Net.FtpClient. The RFC says the server must specify MLST as a feature along with the facts if it supports MLST/MLSD and as you mentioned, MLST is only mentioned on the OPTS line so if the server supports machine listings at all, it's incomplete or broken. I'll do some work on the feature parser to try to overcome this bug.
Mar 27, 2013 at 2:19 PM
The latest revision does a more precise match per RFC2389 which should avoid this problem. Check it out and let me know if it clears up the false positive match for MLST.
Apr 3, 2013 at 12:23 AM
Hi again, sorry been off work for a few days.

I retrieved this response to the FEAT command by debugging the library, with a breakpoint in the GetFeatures(...) method and inspecting the "reply" parameter:
211-Extensions supported
 CSID Name; Version;
 HOST domain
 RMDA directoryname
 THMB BMP|JPEG|GIF|TIFF|PNG max_width max_height pathname
 MFF Create;Modify;
 XCRC filename;start;end
 XMD5 filename;start;end
 XSHA1 filename;start;end
 XSHA256 filename;start;end
 XSHA512 filename;start;end
 COMB target;source_list
The server is an IBM AS400 I think, but not 100% sure. It's external to our organisation.

Looking again at RFC 2389, it seems to me that the response should have had a "211 End" at the end (unless it's already been discarded in the ftpClient at the point where I looked?), and as far as I can understand, the OPTS command is supposed to go from the client to the server - so what the heck is the server doing sending it out?!? I guess I must be missing something, somewhere...

I'll grab the later revision and give it a try.

Thanks again!
Apr 3, 2013 at 4:58 AM
Just to let you know - I tested the change to FtpClient.cs (replacing .Contains(..) with .Trim().StartsWith(..)) and it works fine in my situation.
Cheers - Andrew