Listing (alot of) dirs problem...

[Zio]

Example:

[L] PASV
[L] 227 Entering Passive Mode (my.ip,port)
[L] Opening data connection IP: my.ip PORT: 34362
[L] LIST -al
[L] Connected. Negotiating TLSv1 session..
[L] TLSv1 negotiation successful...
[L] TLSv1 encrypted session using cipher DHE-DSS-AES256-SHA (256 bits)
[L] 150 Opening ASCII mode data connection for directory listing.
[L] List Complete: 260 KB in 2.30 seconds (113.3 KB/s)

vs

[L] LIST -al
[L] Connected. Negotiating TLSv1 session..
[L] TLSv1 negotiation successful...
[L] TLSv1 encrypted session using cipher DHE-DSS-AES256-SHA (256 bits)
[L] 150 Opening ASCII mode data connection for directory listing.
[L] Connection lost: my.ftp

It randomly does this. The dir contains 2864 folders.
In another dir, with aprox. 7000 folders, I can enter the dir and see how FlashFXP is listing the files/dirs in the status window. It counts up to ~245kb, then it shows the dirs/files and hangs. It's not really hanging, but it's actually relisting the dir again. After a couple of seconds it says the scan is complete, ~500kb and the I get connection lost.
It is as if FlashFXP thinks the first list failed, and tries to redo it?
And the result is that it is trying to display ~14000 folders and can't handle it?

Example:
[R] PASV
[R] 227 Entering Passive Mode (some.ip,199,7)
[R] Opening data connection IP: some.ip PORT: 50951
[R] LIST -al
[R] Connected. Negotiating TLSv1 session..
[R] TLSv1 negotiation successful...
[R] TLSv1 encrypted session using cipher DHE-DSS-AES256-SHA (256 bits)
[R] 150 Opening ASCII mode data connection for directory listing.
[R] List Complete: 242 KB in 21.16 seconds (11.4 KB/s)
[R] PASV
[R] 227 Entering Passive Mode (some.ip,199,8)
[R] Opening data connection IP: some.ip PORT: 50952
[R] LIST -al
[R] Connected. Negotiating TLSv1 session..
[R] TLSv1 negotiation successful...
[R] TLSv1 encrypted session using cipher DHE-DSS-AES256-SHA (256 bits)
[R] 150 Opening ASCII mode data connection for directory listing.
[R] Connection lost: some.ftp

The 2nd "LIST -al" is done by the client itself, right after it says the first is done. It actually shows the dirs but seems "hung", until it crasches.

I hade a similar problem with last betas on 2.1.x series, but the worst scenario there was dupes of all dirs/files in the listing window, not the crasching part I experience now.

Both ftpds are running glftpd v1.32. Since I can control my own ftp, I disabled auth TLS, and I tried listing the dir for about 80 times, with NO problems. With Auth TLS enabled it was a 30% chance of failure on my ftp. On the other ftp the failure chance is 100%, since it does the rescan no matter what I do.

Any ideas?

/Zio

[bigstar]

<< I sent you a private message >>

There does appear to be a problem here. If the list fails, depending on the type of failure it will be re-tried once. It would appear that the list is not properly cleared before retrying.

FlashFXP should be able to handle 14000 folders no problem. I've stress tested FlashFXP by loading 50MB dummy list files into FlashFXP without a problem.

We need to see if we can figure out why the connection is failing.

[Ardris]

I've done a bit of a stress test of FlashFXP 3.0.1003 using AUTH TLS/SSL @ 256bit encryption.
FTPd's used were: Serv-U 5, RaidenFTPd, Pure-FTPd, Pro-FTPd, and for good measure, wu-ftpd.

For testing purposes, I created a home directory which contained 25,000 folders -- this tore the life out of my server HDDs, hehe.

I performed 10 connections with successful listing in each case.

This has left me at a blank as to what is going on. Do you have the lastest OpenSSL libraries for the system(s) which glftpd is running on?
Do you have any form of stateful firewall which might be seeing the massive listing as some form of attack and thus severing your connection to the server?

Regards,
Ardris

[darkone]

Make sure you don't have directory size calculation on in gl... otherwise listing huge amounts of directories will take a while