Custom Query (8144 matches)

Currently (FileZilla Client 3.5.1), the target directory doesw not show the actual contents when an upload is completed. The user then has to manually refresh the diretory listing to confirm that the transfered data is there. be a If the directory would automatically refresh, this would not be necessary. Whether the refresh should happen per file transfer or group of transfers could be a user preference, as per file would generate a bit more traffic which might not be necessary for a specific user.

FileZilla version used below:

FileZilla Client

Version: 3.5.1

Build information:

Compiled for: i586-pc-mingw32msvc Compiled on: x86_64-unknown-linux-gnu Build date: 2011-08-28 Compiled with: i586-mingw32msvc-gcc (GCC) 4.2.1-sjlj (mingw32-2) Compiler flags: -g -O2 -Wall -g -fexceptions

Linked against:

wxWidgets: 2.8.12 GnuTLS: 2.10.4

Operating system:

Name: Windows NT 6.1 (build 7601, Service Pack 1) Version: 6.1 Platform: 64 bit system

I happen to have a file named ' 01.xxx.mp3' (xxx was Taiwanese). The whitespace prefixing the file name causes downloading errors. The filezilla server log shows the process.

(000005)2011/10/29 下午 23:56:44 - user (211.76.77.44)> 227 Entering Passive Mode (140,113,205,141,8,75) (000005)2011/10/29 下午 23:56:44 - user (211.76.77.44)> RETR 01.xxx.mp3 (000005)2011/10/29 下午 23:56:44 - user (211.76.77.44)> 550 File not found

Yes, the filezilla client correctly requested the filename as 'RETR 01.xxx.mp3', which has two whitespaces after RETR. It's just the server cannot find it.

The issue can be worked around by deleting the prefixing whitespace. It's weird that when I tried to rename ' 01.xxx.mp3' to '01.xxx.mp3', windows 7 told me a file with that name already exists. I copied that file to the same directory, getting both '01.xxx.mp3' and ' 01.xxx.mp3'. Then, I deleted ' 01.xxx.mp3' and this time I can download '01.xxx.mp3' as usual.

So I'm unsure if this issue belongs to filezilla server or windows 7 or the FTP protocol.

Perhaps the problem is that all whitespaces between RETR and the filename are ignored by filezilla server?

The gnutls_transport_set_lowat function has been removed in >=gnutls-3 which causes a build failure. It was used to disable the lowat feature and apparently this is now always the case.

Therefore, the function shouldn't be used except for versions that require it.