Some severe defects in Flashxp to make me give up using it

lupin · 05-30-2004, 01:58 PM

1. The forever existing bugs:Queue retry problems.(multiple)
2. When a file is larger than a certain size,flashxp
will get the file incorrectly(ex:A 4G file, get it over 4.1G,4.2G....
),then abort,then get again(but from 0Byte,can't resume because
the existing grabbed file is larger than the file in server).
So,the file can never be downloaded completely to your computer
until the end of the world.

I suspect this bug is related to some miscalulating problems.

No program is perfect,but the two bugs are very serious and
annoying and wasting the users' precious time/bandwidth
And the developers are not going to fix it,unless I pay for it
first.

Hetfield · 05-30-2004, 02:15 PM

1) Could you please be more specific on this one? I don't have any problems with the queue handling at all.

2) AFAIK FlashFXP doesn't have any problems with handling big files (that is, larger than 4 GB), however numerous ftpd's have problems with it, so are you sure it's a flashfxp issue and not a ftpd issue? Did you test with several ftpd's or other clients?

bigstar · 05-30-2004, 02:20 PM

1) This is a difference of opinion. As per your previous post There are no current plans to change this behavior. Perhaps in the future the retry logic will be more flexable. But even so I don't believe the file should be immediately re-tried.

Raccoon · 05-30-2004, 02:30 PM

What version of Windows are you using?
What build of FlashFXP are you using?

lupin · 05-30-2004, 08:20 PM

For the retry problem,the server is proftpd 1.2.9.
After desassembling flashfxp.exe,I found the line:
:0053FC2E [***deleted***] cmp word ptr [eax+00000306], 0226

0x226=550

is the key to solve the "550" response problems.
Many friends complained to me about the same problem,but they just thought they can do nothing unless the root modifies proftpd sources and recompiles it.
In real world,the root either is too lazy or has no ability to do it.

For the big file problem,it is very severe in the previous versions.
Some small files will be aborted due to timeout,then reget and resume
correctly but some files will just show "this files can not
be resumed!" and reget from 0Byte.I do not understand because the file
was just downloaded about 50-60 percent.
When I install the 3.0Build 999,99% of the files are ok but only one file has the same situation.
The file has sitting on my server for one month because no build of flashfxp can download it correctly.
The file size is 4.38G.Everytime when I saw the progess showed
"4.35G->4.36G->..." and I thought "finally,almost done!",then
I will see " 4.39G->4.40G....and the precentage became "??%"
I cannot believe my eyes! I press "abort" then "go" icons,
it just delete the big file and restart from 0byte because
the "Overwrite" rule is applied(destination file is larger than server
file" ,no way to resume.

Maybe this is due to another proftpd non-standard response,or
the SSL bugs are not complete solved.

"But even so I don't believe the file should be immediately re-tried."

That depends on if you understand the pain.
If I have 20 directories to download,the first directory has 50 files
inside,12 files are downloaded completely,other 38 files
are marked "failed" in queue. Flashfxp is downloading the second directory. After a long night,flashfxp is downloading directory 15
,but the previous 14 directories are all "broken downloads"
because none of them has finished downloading process.

The reason to reget immediately is the spirit of the queue order:
"Start download queue item2 when item1 is finished".Of course,if
queue item1 is failed ( non-exist file/path),it will proceed to next item. For proftpd+flashfxp situation(very popular),if a
item is queued,it is almost impossible to get "550 not found"
response when downloading.If it is not found on the server,how can
I drag it to queue? If the root deletes the files between the time it is queued and started ,I can remove it from queue later.
But for a configured busy server,the "550 too many download threads under this server" is very often to occur. It is also very tired to press "ctrl+alt+R" many many times
to unmark all failed files.

Raccoon · 05-31-2004, 03:20 AM

I'm at a bit of a lost at the problem you're describing, so I'm not going to try answering it.

I just see you mentioning a 4G file limit, and will explain (what you may already know) about it.

If the FTP server is running on a machine with a Fat32 file system, it may fail to list the files or send them correctly.

If the drive you're trying to download to is on a Fat32 file system, the file will fail at 4G.

If you are using Win95/98/ME, then you are using a Fat32 file system. If you upgraded from these to 2K or XP, then you may be using Fat32.

lupin · 05-31-2004, 04:43 AM

remote: redhat 8.0 Linux with ext3 file system
local:winxp with NTFS file system

lupin · 06-01-2004, 02:52 AM

[L] 227 Entering Passive Mode (1XX,1XX,25,17,134,223).
[L] Opening data connection IP: 1XX,1XX,25,17,134 PORT: 34527
[L] RETR PRV.VIRT.Virtualia.3-The.Dark.Side.rmvb
[L] Connected. Negotiating TLSv1 session..
[L] 150 Opening BINARY mode data connection for PRV.VIRT.Virtualia.3-The.Dark.Side.rmvb (397304010 bytes)
[L] TLSv1 negotiation successful...
[L] TLSv1 encrypted session using cipher DES-CBC3-SHA (168 bits)
Transfer Timed Out
[L] ABOR
[L] 426 aborted by DeleGate
[L] 450 Transfer aborted. Link to file server lost.
[L] Transfer Failed!
[L] PASV
[L] 227 Entering Passive Mode (1XX,1XX,25,17,134,230).
[L] Opening data connection IP: 1XX,1XX,25,17,134 PORT: 34534
[L] REST 343310336
[L] 200 PORT command successful
[L] This file can not be resumed==========================>STRANGE!!!
[L] RETR PRV.VIRT.Virtualia.3-The.Dark.Side.rmvb
[L] Connected. Negotiating TLSv1 session..
[L] 350 Restarting at 343310336. Send STORE or RETRIEVE to initiate transfer
Transferred: PRV.VIRT.Virtualia.3-The.Dark.Side.rmvb 0 bytes in 0.00 seconds (0.1 KB/s)
[L] Transfer Failed!
[L] PASV
[L] 450 Transfer aborted. Link to file server lost.
[L] 227 Entering Passive Mode (1XX,1XX,25,17,134,232).
[L] Opening data connection IP: 1XX,1XX,25,17,134 PORT: 34536
[L] RETR PRV.VIRT.Virtualia.3-The.Dark.Side.rmvb
[L] Connected. Negotiating TLSv1 session..
[L] 200 PORT command successful
[L] TLSv1 negotiation successful...
[L] TLSv1 encrypted session using cipher DES-CBC3-SHA (168 bits)397304010

summary of the above log:
(1) the problem file size is 378.90MB only
(2) The server supports "resume" of files,but sometimes,flashfxp
will show "[L] This file can not be resumed" as in above log.
The result is "Restarting from 0Byte"

Hope this help!!!

bigstar · 06-01-2004, 03:24 AM

I suspect the problem is "DeleGate" the proxy server, it's doing some strange things and it's confusing FlashFXP.

"[L] 200 PORT command successful" <- FlashFXP issued PASV, there's no reason for the ftp server to send a PORT successful reply, FlashFXP is expecting the reply to the REST command.

lupin · 06-01-2004, 06:05 AM

Although not confirmed yet,but I think the problem
has 90% posibility of delegated's responsibility,according
to your analysis.

Thanks very much for your time and help!

New beta build of delegate has fixed some PASV related bugs,
maybe this is one of them.

a1web · 06-02-2004, 01:51 AM

Group hug time