Extremely bad performance with drive mappings

[edwinv]

On machines with drive mappings from a server on a
"not-so-quick" network (200kB/s), FileZilla starts
having huge performance issues. The following symptoms
I noticed:

• very slow start times when multiple large drives are

mapped (I'm talking about minutes)

• slow browsing over the mapped drives. 1-4 directory

entries per second, where the windows explorer manages
a least a hundred times that.

[Tim Kosse]

The Windows API itself is bugged and causes this behaviour.
I would suggest to transfer files using FTP and not using
Windows shares.

[edwinv]

While I have no doubt that the API is bugged, there are
plenty of reasons to assume that something is not right on
the side of FileZilla as well.

• no other application shows the same level of performance

problem (by a huge margin)

• FileZilla is affected by the presence op drive mappings

(startup time), even though they're net used.

Your suggestion is not very helpful as I'm trying to use it
at work for transfering files from remote servers. I have
no choice but to accept the presence of the corporate
network. And as I'm not willing to remove the problematic
drive mapping and remap them after using FileZilla, it's
basically the blocking bug for me.

[edwinv]

While I have no doubt that the API is bugged, there are
plenty of reasons to assume that something is not right on
the side of FileZilla as well.

• no other application shows the same level of performance

problem (by a huge margin)

• FileZilla is affected by the presence op drive mappings

(startup time), even though they're net used.

Your suggestion is not very helpful as I'm trying to use it
at work for transfering files from remote servers. I have
no choice but to accept the presence of the corporate
network. And as I'm not willing to remove the problematic
drive mapping and remap them after using FileZilla, it's
basically the blocking bug for me.

[anonymous]

Logged In: NO

This might be the problem in bug#988100 (filezilla runs but no
GUI appears) ?

[Tim Kosse]

This bug report has been closed due to inactivity and has possibly
already been solved.

You can reopen this report if the issue still exists in the
latest version of FileZilla (Server).

[miqrogroove]

I'm having a really bad time with FileZilla local file list when used with My Documents redirected to a network path over VPN. The symptoms are the same as above. The FTP site loads quickly, but the My Documents file list loads so slowly that the program is unusable. I have not experienced this problem in any part of Windows or any other application. It is specific to FileZilla only.

[Tim Kosse]

Uninstall any virus scanner and other so-called security solutions. FileZilla merely asks Windows for a list of files and their attributes. Looks like some broken scanner thinks it's a good idea to read in all the files over the network before allowing a program to list the file attributes.

[miqrogroove]

Replying to codesquid:

Uninstall any virus scanner and other so-called security solutions. FileZilla merely asks Windows for a list of files and their attributes. Looks like some broken scanner thinks it's a good idea to read in all the files over the network before allowing a program to list the file attributes.

Not the least bit helpful and it's lame that you try to blame a bug on other software. I do not use a virus scanner. Your explanation is invalid.

[miqrogroove]

8 years, still broken. :(

[miqrogroove]

FWIW, the extremely bad performance can be limited by the number of files being displayed in the local window. By reducing the window size, it will only take several seconds instead of minutes to show each directory. This problem remains quite specific to FileZilla and does not appear in any other program.

[Olaf Leimann]

Replying to miqrogroove:

FWIW, the extremely bad performance can be limited by the number of files being displayed in the local window. By reducing the window size, it will only take several seconds instead of minutes to show each directory. This problem remains quite specific to FileZilla and does not appear in any other program.

Finally found the right entry matching my problem of over a year or two :)

Basically, it's obvious from the user that Filezilla is not just using normal file and directory APIs to quickly load the information into the window, because other applications manage to do that from the same share 100 times faster.

It also seems to happen more if you change the local site quickly after having started filezilla, or does not happen when filezilla already took a long time in starting.

It's as if there some seperate process that has to finish before any mapped drives
can be accessed quickly. After the first (slow) local site entry, the other appear a lot faster as well.

[Olaf Leimann]

Replying to oleimann:

One note: this did NOT happen with (much) older versions of Filezilla, however
I'm not sure from which version onwards this started going wrong.
I think I remember that the site editor was still in an older format.

[Olaf Leimann]

Just noted that it does not happen after starting FileZilla, only after using FTP to connect, and then changing the local site (current 3.5.3 version - just freeshly installed/upgraded).

[miqrogroove]

Would it be possible to get this fixed so that I don't have to upload and download all of my files to a temporary folder? Isn't 9 years of this enough?

[Rocky]

Yes, this has been a repeatedly reported issue for years. It has consistently been shot down as "it's Windows fault, not FileZilla." Yes, it may indeed be someone else's fault, but please update FileZilla to work around this issue so network drive performance is consistent with other applications. Please! FileZilla is such a superior FTP client, and I've been forced to use another solution for a long time because of the network drive performance problem and would like to switch back. I'm sure there are lots of us in the same situation.

[Justin]

Replying to RockyMoose:

Yes, this has been a repeatedly reported issue for years. It has consistently been shot down as "it's Windows fault, not FileZilla." Yes, it may indeed be someone else's fault, but please update FileZilla to work around this issue so network drive performance is consistent with other applications. Please! FileZilla is such a superior FTP client, and I've been forced to use another solution for a long time because of the network drive performance problem and would like to switch back. I'm sure there are lots of us in the same situation.

I'm in exactly the same situation that RockyMoose and many others describe. Network drive performance with FileZilla is terrible, and the only thing worse is the sad response from the developers that this is some "windows issue" or "virus scanner issue". We get taken for fools who don't know how to troubleshoot, rather than being taken serious with what is certainly a FileZilla issue.

I (tried to) use FileZilla at home, and at work to upload files from our network shares (mapped network drives) to customer-facing FTPs. Directory listings on the network share take ages because it shows them at a rate of about 1 directory/file per second or two. Downloading them to my local machine first, or showing only a few files at a time, is not an acceptable workaround.

Here's a summary of why it's clearly a FileZilla issue:

1) Windows Explorer does NOT experience this issue at all, and displays the directory listing pretty much instantly, regardless of whether I'm sitting next to the server the share is on, or halfway across the globe.

2) Other FTP Clients tested do NOT experience this issue at all, as above.

3) Virus Scanners and IPS/IDS Systems disabled and the issue persists.

4) Happens even with directly connected network drives, so it's not a network issue.

5) FTP Sites with a far slower connection load instantly, again reinforcing point 4.

6) Apparently doesn't happen with very old versions of FileZilla (haven't tested myself)

I'd even be willing to demonstrate the issue in a remote session if necessary. Will someone please take this issue seriously and resolve it finally? FileZilla is otherwise a great solution and I'm not the only one who'd like to be able to use it again.

[Daniel Beardsmore]

I used to think that the file-by-file lag on local files was down to Office 2003's grip on various file types, and indeed I did increase the speed by disentangling the Office XML/HTML preview handlers (since FileZilla seems to invoke those even for icons too small to show previews).

However, having upgraded to a Windows 10 PC (Core i5) with 64-bit FileZilla, I was surprised to find that FileZilla was substantially slower at drawing local listings than it was on my Core 2 Duo XP PC. Having done some digging I've come to discover that it's only network shares that suffer this problem. I have my Desktop and Documents folder redirected, just as I did on the PC before.

Just to give an idea, a 46-file directory containing HTML files takes around 1.25 seconds to draw in the file entries in the window. Browsing directories local to C: is of course instantaneous. It's not hugely slow, but there's clearly something very wrong with way that directory listings are queried.

As prior users have noted, this delay isn't present outside of FileZilla, and it's not related to AV (of which I had none installed on the old PC, and disabling Windows Defender in 10 makes no difference).

There are various horrible network-related file browsing delays in Windows, such as browsing a volume over a VPN, or browsing a virtual volume created by RDP (e.g. local drive C mapped remotely as
tsclient\C), the latter being atrociously slow in some cases. Since even Explorer can fall victim to horrible directory listing lag, I figure that whatever FileZilla is doing has a small amount of overhead on a per-file basis that accumulates until the delay results in the program taking a very long time to list a directory.