Open anandgmenon opened 3 weeks ago
My understanding from the code is FluentFTP checks if MLST is supported on the server or else fallback to get folder listiting to get the file metadata.
Correct.
Do we have a bug in this logic ?
I hope not.
But it sure looks like it at first glance.
Here's the what the RFC's say: ( see here )
Non-Standard servers, unfortunately, advertise all sorts of wrong things. Like for example, they advertise MLSD. Per RFC, this doesn't even exist as a valid advertisement. But, in our experience this means that the server supports MLSD and MLST.
This server of yours, it advertises "MLSD" (<-bug #1) and probably wants to say, it supports MLSD but not MLST(<-bug #2).
#1: MLSD is not a RFC allowed FEAT extension advertisement at all #2: Command MLSD alone (with no MLST comment) is not a RFC allowed extension configuration
So FluentFTP then sets its flag, and MLST is used.
What to do now? Correct FluentFTP's gracious acceptance of (many) servers reporting MLSD and really meaning MLST and MLSD? Or handle this (one) server, which is also doing something incorrect, by not** using MLST?
Note that both are in the wrong. If we change FluentFTP's code to be RFC strictly compliant, both of the miscreants will suffer.
@robinrodricks
The capability should be called MLST in the code and not MLSD. Global rename needed. The capability is currently correctly set when we see a FEAT response of MLST. This is currently done correctly. The capability is currently also set when we see a FEAT response of MLSD. <- and this causes the problem. The problem is: This is actually good for most misbehaving servers, but not good for the one causing this issue.
The capability should be called MLST in the code and not MLSD. Global rename needed. The capability is currently also set when we see a FEAT response of MLSD. <- and this causes the problem.
I think we should introduce a new capability called MLST in addition to MLSD. Rename or not, I think here the better solution would be:
Is this a workable solution?
FTP server appears to be Axway MFT as per the logs. I have never heard of this server before, and we do not have any FTP server detection logic for this either.
If the server only advertises MLSD, then we only allow MLSD commands
I have no inkling how many clients out there rely on MLSD and MLST being allows if only MLSD is advertised, which is the current implementation.
FTP server appears to be Axway MFT as per the logs. I have never heard of this server before, and we do not have any FTP server detection logic for this either.
Wow, where does this appear in the log, I am blind. Edit: Yeah, Google is our friend, ok.
Is this a workable solution?
Well, making MLST and MLSD separate capabilites would make it easier to differentiate. So much is clear. It still leaves the interpretation of only MLSD up to grabs: Either fix this issue and hurt some other users or vice versa. I don't know the numbers and I don't know the facts.
The behaviour when "only MLSD" is present: Either we recognize the AxWay Server (which I would prefer, maybe), or we make it configurable by the user.
Either we recognize the AxWay Server (which I would prefer, maybe),
I would also prefer this. I am just a bit unhappy that the server does not specify its name in the welcome message. But this would be the best way because it would "automatically" work for all new users without having to configure or setup anything.
My proposed solution would be:
MLSDIsExclusive = true
which indicates that MLSD does not imply MLSTMLSDIsExclusive = false
, which means both are synonymous // return true if we can use MLST commands
CanUseMLST(){
if (MLSDIsExclusive){
return FtpCapability has MLST;
}else{
return FtpCapability has MLSD or FtpCapability has MLST;
}
}
// return true if we can use MLSD commands
CanUseMLSD(){
if (MLSDIsExclusive){
return FtpCapability has MLSD;
}else{
return FtpCapability has MLSD or FtpCapability has MLST;
}
}
I am just a bit unhappy that the server does not specify its name in the welcome message
Full Ack.
- We will detect the AxWay server somehow
Hmmm.
10.2.242.199 FTP server 5.5-20220825 ready.
ipaddress "FTP server" n.n-date(yyymmdd) "ready."
How safe would a grep for this be? Risky
ipaddress "FTP server" n.n-date(yyymmdd) "ready."
Its quite specific. It should work.
FTP Server OS: Unix
FTP Server Type: Axway
Client Computer OS: Windows
FluentFTP Version: 49.0.2
Framework: .NET 6
Hey I'm back with another issue/question. So one of our users faced an issue with the
GetObjectInfo()
method. It seems to be returning _Response: 500 'MLST /CER/INBOX/TESTCLM.096FB412.20240820161946524': command not understood. See detailed logs below. My understanding from the code is FluentFTP checks if MLST is supported on the server or else fallback to get folder listiting to get the file metadata. Do we have a bug in this logic ?Logs :