Wildcard bug in FileZilla 1.1.0

Need help with FileZilla Server? Something does not work as expected? In this forum you may find an answer.

Moderator: Project members

Post Reply
Message
Author
elminster44
500 Command not understood
Posts: 3
Joined: 2021-11-10 20:45
First name: Simon
Last name: V

Wildcard bug in FileZilla 1.1.0

#1 Post by elminster44 » 2021-11-10 21:05

Hi, i think there is a bug in the latest FZ server that prevents any use of wildcards when the client list files or directories. It also does not seem to work with the MGET command. Tried searching for a fix but found none. I had to reinstall version 0.9.60 to solve my problem as most of my automation script broke as a result. Is there any workaround or are you planning a fix in a future release?

Sorry, i don't have a log as i was in panic mode when all my script stopped working. apparently when you uninstall the 1.1 version it removes the logs that go with it (that or it didn't create any in the few hours it was installed)

Thanks for the help!

User avatar
botg
Site Admin
Posts: 35492
Joined: 2004-02-23 20:49
First name: Tim
Last name: Kosse

Re: Wildcard bug in FileZilla 1.1.0

#2 Post by botg » 2021-11-10 23:50

"MGET" is not a specified FTP command. At best, it is a commonly used client-side command in command-line clients that is turned into a sequence of a plethora of different FTP commands.

FTP itself does not specify any wildcard syntax. Any client-side wildcard support needs to be implement by the client by the means of wildcard-agnostic commands and appropriate client-side filtering. Any client that doesn't do so relies on unspecified or undefined behavior that isn't portable across servers.

Please contact your client vendor for further assistance.

elminster44
500 Command not understood
Posts: 3
Joined: 2021-11-10 20:45
First name: Simon
Last name: V

Re: Wildcard bug in FileZilla 1.1.0

#3 Post by elminster44 » 2021-11-11 01:38

Thanks for your quick answer. Could you elaborate on how can this be a client side issue? My script using MGET is working fine with FileZilla server version 0.9.60 (and all previous version of FZ servers I had for the past few years), Ubuntu FTP servers, IIS FTP servers ... it stopped working when i upgraded to FileZilla version 1.1 and started working again when i downgraded back to version 0.9.60. Never had any issues on any other platforms, been running it for a very long time.

It is a very basic script.
  1. Open connection
  2. download all file present in a folder (with MGET)
  3. Close connection
I'm still hoping to get to the bottom of this, so i reinstalled version 1.1 and tried it again. Here are the log entries on the server side when trying "MGET *"
2021-11-11T01:27:42.612Z >> [FTP Session 1 127.0.0.1 user] TYPE A
2021-11-11T01:27:42.612Z << [FTP Session 1 127.0.0.1 user] 200 Type set to A
2021-11-11T01:27:42.613Z >> [FTP Session 1 127.0.0.1 user] PORT 127,0,0,1,4,46
2021-11-11T01:27:42.613Z << [FTP Session 1 127.0.0.1 user] 200 PORT command successful.
2021-11-11T01:27:42.614Z >> [FTP Session 1 127.0.0.1 user] NLST *
2021-11-11T01:27:42.614Z << [FTP Session 1 127.0.0.1 user] 450 Couldn't open the file
2021-11-11T01:27:42.615Z >> [FTP Session 1 127.0.0.1 user] TYPE A
2021-11-11T01:27:42.615Z << [FTP Session 1 127.0.0.1 user] 200 Type set to A


on the client side, I have:
200 Type set to A
Cannot find list of remote files.

User avatar
botg
Site Admin
Posts: 35492
Joined: 2004-02-23 20:49
First name: Tim
Last name: Kosse

Re: Wildcard bug in FileZilla 1.1.0

#4 Post by botg » 2021-11-11 08:39

MGET is never sent over the wire. Your client converts it into a sequence of a plethora of different FTP commands. Your client doesn't do this conversion in a portable way and instead relies on server-specific unspecified or undefined functionality. Your client vendor needs to fix the client so that it doesn't rely on particular server behavior.

elminster44
500 Command not understood
Posts: 3
Joined: 2021-11-10 20:45
First name: Simon
Last name: V

Re: Wildcard bug in FileZilla 1.1.0

#5 Post by elminster44 » 2021-11-11 13:30

OK, well, we have this issue when running the script on my Linux RH VM and also on my Microsoft Windows 10 computer when I did some test. I don't think I will have much success contacting MS or RH to have them change the way their FTP client behave especially when the problem only occurs on one version of FileZilla servers and not anywhere else (to my knowledge). I'm sure they will throw you back that ball and I certainly do not have the time to play man in the middle.

I totally get where your cumming from, if all programmers had the mindfulness to use best practice in programming, we certainly would have better programs and fewer bugs. Unfortunately, this is a battle that I will leave to others, I have a very specific issue, and my quickest solution is to simply stick with version 0.9.60 for now and to find another FTP server in the long run, one that I will be able to patch with the latest security fix. Please do not take my comment as bitching. I truly admirer what you’re doing and I relied on Filezilla both client and server for a very long time. I love what you've done with it, and will definitely reinstall it from time to time to see if this issue would not get accidentally fixed in the future.

Keep up the good work,
Cheers!

Dustrunn3r
500 Command not understood
Posts: 1
Joined: 2021-11-24 13:27
First name: Kasper
Last name: Bjerrum Pedersen

Re: Wildcard bug in FileZilla 1.1.0

#6 Post by Dustrunn3r » 2021-11-24 13:35

Hi.

Same issue today. Upgraded a FileZilla server from one customer from v. 0.9.60 to v. 1.1.0 where the client is using a wget filenameandthen* and on the 1.1.0 we are getting this in the log: Cannot find list of remote files.
We then did a downgrade to 0.9.60 and then the same script with wildcard worked.

Is there a FileZilla Server upgrade down the road regarding this wildcard issue?

Kasper

User avatar
botg
Site Admin
Posts: 35492
Joined: 2004-02-23 20:49
First name: Tim
Last name: Kosse

Re: Wildcard bug in FileZilla 1.1.0

#7 Post by botg » 2021-11-24 16:58

Your client needs to be updated to not rely on unspecified functionality.

Marangal
500 Command not understood
Posts: 1
Joined: 2021-12-10 09:06
First name: Jonas
Last name: pandelaere

Re: Wildcard bug in FileZilla 1.1.0

#8 Post by Marangal » 2021-12-10 09:13

Hi We have an issue that looks the same when upgrading rom v. 0.9.* to v. 1.1.0.

After sending command: Sending command 'LIST *'
we get: '450 Couldn't open the file'

Reading above I think we will need to return to the older version.

I found some info about LIST command maybe not supported anymore, and using MLSD instead.
https://stackoverflow.com/questions/150 ... 1#16652371

Logs:

Code: Select all

Sending command 'PASV'
Sending command 'PASV'
⇦
⇨ with 227 Entering Passive Mode (10,252,31,168,206,135)
⇨ with 227 Entering Passive Mode (10,252,31,168,206,135)
⇦ with (227 Entering Passive Mode (10,252,31,168,206,135), 227)
ftp server returns reply '227 Entering Passive Mode (10,252,31,168,206,135)'
ftp server returns reply '227 Entering Passive Mode (10,252,31,168,206,135)'
⇨
⇨ with com.sap.aii.adapter.file.ftp.FTPPassiveDataSocket@4321adc8
⇨ with com.sap.aii.adapter.file.ftp.FTPPassiveDataSocket@4321adc8
⇦
[color=#FF4000]Sending command 'LIST *'
Sending command 'LIST *'
⇦
⇨ with 450 Couldn't open the file
⇨ with 450 Couldn't open the file
⇦ with (450 Couldn't open the file, [Ljava.lang.String;@28a7a51e)
ftp server returns reply '450 Couldn't open the file'
ftp server returns reply '450 Couldn't open the file'[/color]
⇨
⇨ with [Ljava.lang.String;@5691fda0
⇨ with [Lcom.sap.aii.adapter.file.io.FileHandle;@621fbd3f

User avatar
oibaf
Contributor
Posts: 396
Joined: 2021-07-16 21:02
First name: Fabio
Last name: Alemagna

Re: Wildcard bug in FileZilla 1.1.0

#9 Post by oibaf » 2021-12-10 09:30

In your specific case, there's really no point in using a wildcard with LIST: by default LIST just returns the full content of the directory it's asked to list.

Just remove the wildcard and LIST will list the current directory in full.

User avatar
boco
Contributor
Posts: 26899
Joined: 2006-05-01 03:28
Location: Germany

Re: Wildcard bug in FileZilla 1.1.0

#10 Post by boco » 2021-12-10 10:13

The problem is that the behavior is often hardcoded and not changeable by the user.

What harm would it do to implement it, just for backward compatibility, with an option "Allow wildcards in list commands". As @botg said, it doesn't actually violate any standards.
### BEGIN SIGNATURE BLOCK ###
No support requests per PM! You will NOT get any reply!!!
FTP connection problems? Please do yourself a favor and read Network Configuration.
FileZilla connection test: https://filezilla-project.org/conntest.php
### END SIGNATURE BLOCK ###

User avatar
botg
Site Admin
Posts: 35492
Joined: 2004-02-23 20:49
First name: Tim
Last name: Kosse

Re: Wildcard bug in FileZilla 1.1.0

#11 Post by botg » 2021-12-10 13:12

The harm is long-term, if there would be such an option there is no pressure for bad clients to change to not rely on unspecified behavior.

lugatti@indacoproject.it
504 Command not implemented
Posts: 8
Joined: 2021-12-29 08:21
First name: G.
Last name: L.

Re: Wildcard bug in FileZilla 1.1.0

#12 Post by lugatti@indacoproject.it » 2022-01-01 15:25

boco wrote:
2021-12-10 10:13
The problem is that the behavior is often hardcoded and not changeable by the user.

What harm would it do to implement it, just for backward compatibility, with an option "Allow wildcards in list commands". As @botg said, it doesn't actually violate any standards.
I fully agree with what my colleague said.

We too started from the bottom up with few customers and have been using FileZILLA Server ever since, finding it sufficient for our purposes.

Over the years, increasing our customers, we have become a large company with thousands of customers all over the world and this "unexpected forcing" has surprised us, and not a little.

I ask you please, from technician to technician, think again.

Give us the opportunity to activate the wildcards of your choice under our full responsibility.

After all, it doesn't take much: like for example inserting a register in [HKEY_LOCAL_MACHINE \ SYSTEM \ CurrentControlSet \ Services \ filezilla-server]
that allows the activation of standard GLOBBING or not.

PaJi@atlas.cz
500 Command not understood
Posts: 1
Joined: 2022-01-02 14:57
First name: Pa
Last name: Ji

Re: Wildcard bug in FileZilla 1.1.0

#13 Post by PaJi@atlas.cz » 2022-01-02 15:25

Hello Botg and Boco,

I was very surprised too, that you stopped support of wildcards, which support more than 90 % FTP servers. I will have to downgrade back to the previous version 0.9.60-2 from version 1.2. I tested logins etc. but really I didn't expect that you "destroy" the previous functionality.

Please think that it is big differences between theoretical people created RFCxyz and practice. Stopping the wildcards was not good idea, especially when the previous version did it.

I cannot change the hard coded routines from AS400 in foreign countries. I am servicing the FTP servers like the data-storage only. But I know that nobody will rewrite a lot of hardcoded routines.
Therefore I suggest the same like from <lugatti@indacoproject.it>. Enable wildcards by some "hidden" parameter by service register, or like checkbox in settings. Sure under our full responsibility (no problem).

We use this older technology - FTP, because it seems me that it is one of the most reliable transfer of the many types of files and simple implementation between many OS (Unix, Windows, AS400, etc.).
I like the file-zilla server FTP and philosophy ("simple" and easy), but the wildcards limit me (completely).

Thanx

PaJi

User avatar
boco
Contributor
Posts: 26899
Joined: 2006-05-01 03:28
Location: Germany

Re: Wildcard bug in FileZilla 1.1.0

#14 Post by boco » 2022-01-03 02:42

botg wrote:
2021-12-10 13:12
The harm is long-term, if there would be such an option there is no pressure for bad clients to change to not rely on unspecified behavior.
The most used client for scripting (for simplicity) is Windows ftp.exe and it hasn't moved anywhere in the last decades. Do you really expect it to move on now? I don't think so.

The behavior is unspecified, not forbidden. Means you can support it (via advanced ways as proposed) without breaking any rules of FTP. FTP is a legacy protocol, it will not get any big changes anymore. Don't make it harder for the few fans FTP still has.
### BEGIN SIGNATURE BLOCK ###
No support requests per PM! You will NOT get any reply!!!
FTP connection problems? Please do yourself a favor and read Network Configuration.
FileZilla connection test: https://filezilla-project.org/conntest.php
### END SIGNATURE BLOCK ###

globox
500 Command not understood
Posts: 1
Joined: 2022-07-28 13:43
First name: Julien
Last name: Leclerc

Re: Wildcard bug in FileZilla 1.1.0

#15 Post by globox » 2022-07-28 13:56

This behavior was the very bad surprise of our upgrade from filezilla 0.9.6 to 1.5 today.

After having migrated over 150 accounts and a fileshare of over 300GB and thousands of folders we discovered after 2 days that lots of scripts were breaking because of error "550 couldn't open the file or directory". After an hour of searching we finally pin pointed it down to this topic which explains exactly our problem, wildcards are no longer working with list or nlist ...

The rollback has been done, we are again on 0.9.6...

That you guys want to be RFC Nazis is a thing, but at least implement this with a checkbox to be able to have this working (and a little disclamer that it's bad to use wildcards if you like). We will move from Filezilla server to something else if this features isn't developed, going through hundreds of complex ETL scenarios in order to implement a multi linear code that replaces a single wildcard would be madness.

You might say, that you don't care, but I really hope that you will reconsider.

Post Reply