Empty file listing with Filezilla 3.2.4 - MLSD problem ?

[antarex]

Hi

Since the upgrade to Filezilla 3.2.4, we cannot see the filelisting anymore... i've seen in the changelog that with this version, MLSD become the default command and i suspect that it's the origin of my problem, as the previous versions was using LIST, and worked flawlessly... i'm wondering if there is a way to disable MLSD to use LIST as before...

Here's an extract of the debug log of the MLSD command (i just left a few files, i do not think the whole list is needed ) :

Commande : MLSD
Contenu : type=cdir;modify=20090427094639;UNIX.mode=0705 /
Contenu : type=file;size=24;modify=20040213013218;UNIX.mode=0644 .bash_logout
Contenu : type=file;size=191;modify=20040213013218;UNIX.mode=0644 .bash_profile
Contenu : type=file;size=124;modify=20040213013218;UNIX.mode=0644 .bashrc
Contenu : type=file;size=22;modify=20040213013219;UNIX.mode=0644 .htpasswd
Contenu : type=dir;modify=20050312070905;UNIX.mode=0755 albumphotos.info
Contenu : type=dir;modify=20050621114621;UNIX.mode=0705 antarex.be
... cut here ...
Réponse : 150 Data connection accepted from 217.112.179.19:53376; transfer starting.
Réponse : 226 Listing completed.
Statut : Succès de la lecture du contenu du dossier

The log told that the transfer is successful, but FileZilla does not show anything in the listing...

Is there anything wrong with the answer of the server ? Is there anything i can do to force FileZilla to use LIST such as previous versions (wich obviously work correctly for me) ?

[botg]

Your server is broken, it doesn't terminate the final fact with a semicolon as required by RFC 3659.

Please contact the server administrator so that he can upgrade to a proper server.

[antarex]

I would prefer continue to use LIST, to avoid this kind of compatibility problem, how can i configure Filezilla to use LIST in place of the wrongly implemented (server side) MLSD ? I've constated the same problem with many different servers, it could take months/years before every server on the net is fixed/updated...

When i would like to drink, i drink water if the orange juice is outdated, i do not tell "i will not drink for 10 days until i receive new orange juice"

[botg]

Use alternative servers then.

[boco]

Please make it switcheable botg. Sometimes I want to force LIST.

[antarex]

I understand your point, but the fact is that those servers work with *any* ftp client, except the latest filezilla... even the older versions of filezilla work flawlessly... it seems strange to me that implementing a new protocol into filezilla mean that filezilla cannot work with the standard basic protocol...

I understand and approuve that Filezilla implement new protocols, but it would be nice to implement those protocols without breaking what's working before, without breaking oldest protocols, or at least allowing the users to disable those protocols knowed to cause so much problems...

My current point of view : from one day to another, filezilla stopped to work for 50% of the servers i work with, if i do not have a solution to allow filezilla to work like any other ftp client, i will not make the choice to work only with 50% of my customers, but to use another ftp client...

Of course, you do not care if i use filezilla or another software, and you are right, but i would suggest that you consider this point of view to evaluate if you want to make a software working with most of the servers, even oldest one only respecting the basic FTP protocol RFC, or a limited software only working with latest ftp servers implementing latests protocols... is it so problematic to allow the users to choose to use or not newest protocols ?

[boco]

implementing a new protocol into filezilla

Where did he implement a new protocol? MLSD is just a (better) way of getting lists. It has been around for a long time and is well standardized. Obviously that does not prevent server developers from implementing buggy solutions.

Every fact, including the last one, MUST contain a terminal semicolon. The RFC clearly states that. Other, probably paid, clients rather implement hacky workarounds than to confront server devs with their bugs.

RFC3659, chapter 7.4

[botg]

RFC 3659 is very well defined, it gives a very concise grammar how the entries in a MLSD listing are supposed to look like. If a server claims to support MLSD by including MLSD or MLST in its FEAT response, then it just has to follow the specifications.

Fix those servers, specifications are the law of the interoperable Internet.


I already took much heat concerning the TLS issues and made myself very unpopular with the necessary "file change, upload?" prompts. I'll survive this issue too by doing the right thing.

[boco]

I'd issue a big fat naggy warning and fall back to LIST.

[antarex]

RFC 3659 is very well defined, it gives a very concise grammar how the entries in a MLSD listing are supposed to look like. If a server claims to support MLSD by including MLSD or MLST in its FEAT response, then it just has to follow the specifications.

I fully agree that it's a problem with the server if it does not work correctly with FTP extensions, but it's not the point... the point is : if a server does not work correctly with FTP *extensions*, an FTP client should be able to connect using strictly the ftp rfc protocol (959 ?) without extension... it should be able to disable any extension not compatible with FTP basic protocol... mostly if those extensions does not work correctly with a lot of servers...

The purpose of an FTP client is to work with *any* ftp server respecting RFC 959... be able to work with extensions is a plus, but only able to work with servers correctly implementing those extensions and loosing compatibility with servers wich not is not an evolution for me but a regression...

[antarex]

I've done some search on the subject to know a little more about MLSD...

Here's an extract of the FEAT reply of the servers on wish i have tha problem :

Réponse : 211-Extensions supported:
Réponse : CLNT
Réponse : MDTM
Réponse : MLST type*;size*;modify*;UNIX.mode*;UNIX.owner;UNIX.uid;UNIX.group;UNIX.gid;unique
Réponse : PASV
Réponse : REST STREAM
Réponse : SIZE
Réponse : TVFS
Réponse : Compliance Level: 19981201 (IETF mlst-05)
Réponse : 211 End.

I've thus looked the IETF mlst-05 that the server announce... this IETF clearly state the following format :

facts SP pathname CRLF

Thus, facts, seperated by semi-column (;) followed by a space char, then the filename... It seems for me that the server correctly respect this format...

Contenu : type=cdir;modify=20070823043115;UNIX.mode=0705 /
Contenu : type=file;size=24;modify=20050207161858;UNIX.mode=0644 .bash_logout
Contenu : type=file;size=191;modify=20050207161858;UNIX.mode=0644 .bash_profile

Thus, it seems that it's not the server wich is broken, but filezilla client wich does not recognize the compliance level announced and expect a newer release of the RFC... the server clearly announce in the FEAT reply that the features supported does not include the latest RFC one, filezilla should thus not consider that the server support MLSD latest release.

[botg]

Since almost 10 years now (since mlst-07) the trailing semicolon is required. No wonder the whole world goes downhill with such lazy server developers and server administrators.

[antarex]

The point is that the server clearly state that it support only the mlst-05, we are talking about an FTP server, extensions like RFC 3659 are not mandatory for the FTP protocol... i expect first from filezilla that it respect the standard FTP protocol and work with an FTP server using standard FTP protocol... if filezilla want to use an extension, it must first be sure that the server support this extension, it's not the filezilla team job to decide that RFC 3659 extension must become mandatory... in my case, the server clearly announce that it does not support the MSLD command as described in MSLT-07 and later RFC 3659, but filezilla still want to use it...

It's not my purpose to judge anyone using an FTP server fully compatible with the basic FTP protocol if he do not upgrade his server to support newer RFC not mandatory... if it isnt broken, dont fix it... the standard FTP protocol work great for much more than 10 years, not everyone need newer extensions... more extensions you implement, bigger is the risk to face a bug...

You told that the server is broken, after debugging it seems not, it's filezilla wich does not recognise correctly if the server is compatible with MLSD or not, even if the server clearly state it's not compatible in the FEAT reply. Filezilla should not use MLSD in this case, filezilla is broken if it try to use MSLD on a server wich clearly state that it does not support the MSLD version expected by filezilla. i suppose that's the reason why the "Compliance Level" information has been defined in the IETF and RFC, if filezilla use the FEAT information to determine the compatibility of the server, it should use the whole information and not only a part of it and (wrongly) guess the rest.

Now if you want to modify this thread to judge server admins, i think it's not the place, for me i would like just to speak about filezilla, i was thinking it's the purpose of this forum... After this exchange of information, the question become this : should filezilla remain compatible with standard FTP or should filezilla only support FTP extensions described in RFC 3659... this question is of interest i think...

[botg]

mlst-05 is expired.

[antarex]

To be short and clear : thus, filezilla should not use the MLSD command on a server not supporting it.