site to site transfer problem

[DelPiero]

Everytime i try to transfer a file from one site to another it says Transfer complete but the destination file is always incomplete (a few Kb). When i try to resume the download this happens:

(i'm using alternative method since it's the only one that works)

TYPE I
200 Type set to I.
TYPE I
200 Type set to I.
PASV
227 Entering Passive Mode (XXXXXXXXXXX).
PORT XXXXXXXXXXXXX
200 PORT Command successful.
REST 14864832
350 Restarting at 14864832 - send STORE or RETRIEVE to initiate transfer.
RETR XXXXXXXXX
150 Opening BINARY mode data connection for XXXXXXX
REST 14864832
226 Transfer complete.
350 REST supported. Ready to resume at byte offset 14864832.
STOR XXXXXXXX
150 Data connection accepted from error:error; transfer starting for XXXXXXXX

And the download never stops until i abort it.

Can anybody help me?

Thanks in advance and sorry for my english.

[oxygene]

I think it would be helpful for bigstar, when you include your FFXP build number in your post ;)

[DelPiero]

I've tried version 1.4.4 build 855 & the latest version 2.0 RC2 and them both fail.

[MxxCon]

quiet a few people reported this "error:error" problem...
do you know what ftpd reported it?

[DelPiero]

Originally posted by MxxCon
quiet a few people reported this "error:error" problem...
do you know what ftpd reported it?

I'm not sure if you're speaking about this but it was an UNIX L8 system.

[MidKnight]

and i bet that any of the files that report this "error:error" are anywhere anywhere from 1 to 10k short of being complete?

I'm sorry to tell you this, but i love FlashFXP, and i would never change or move away from it, but your going to have to use another client. i have to use smartftp for fxp transfers. Wihich also brings me to another note, if you do use another client, you will be able to resume the remaining few k of your files, but they will be corrupt, so you will be need start the files again.

----
i just re-read your post and didn't see this, so i was right..

destination file is always incomplete (a few Kb).

[DelPiero]

Thanks for the help. These errors only happen when using the alternative method, the normal one works ok.

[MxxCon]

DelPiero, not exactly, that's "type" of FTP server. i'd like to know exact software and perhaps exact version number. it's often one of the 1st few lines in welcome message during login.

MidKnight, do we have to use a jackhammer to get it into your head that flashfxp doesn't see any data during fxp can not possible cause this error.
geez:mad:
compare status logs from flashfxp and smartftp and see that they are exactly the same

[DelPiero]

Originally posted by MxxCon
DelPiero, not exactly, that's "type" of FTP server. i'd like to know exact software and perhaps exact version number. it's often one of the 1st few lines in welcome message during login.


You mean something like this: 220 Serv-U FTP Server v4.0 for WinSock ready...?

The server that causes the error doesn't provide this information

[ErnestC]

i have the same problem

I tick the alt.FXP downloading

after the file transfer , sometime the size is smaller then the source.

i use Flashfxp 2.0 RC2build 862 / 1.4.3 build 835 have same problem

is there any way to fix ?

i was happy in the first few days, since it is only using port mode when FXP.

But now it appear the

227 Entering Passive Mode (XX,XX,XX,XX,103,205).
PORT XX,XX,XX,XX,103,205
200-FXP transfer: from XX.XX.XX.XX to XX.XX.XX.XX
200 PORT command successful


then all file die

[StarBuG]

I have no problems at all with FXP!

I do it very often and nerver saw this problem!

With any build!

Greetings

StarBuG

[maclaeden]

I notice that whenever I get incomplete files fxping, and whenever other people in this forum report the problem and post their logs, Flashfxp ALWAYS does the RETR command before the STOR. This seems like a bad method, and could very well be the problem, because the sending ftp server *could* start sending before the receiver is ready, and the beginning data could be lost that way. This would also explain the connections to "error:error" for sending small files or resuming small amounts of data: the sender sends a few kilobytes and closes the connection before the receiver is ready.

I can't test to find out if the command order IS causing incomplete files, but it seems like always doing the STOR before the RETR would be a good idea anyway, since there's no potential for this problem that way.

*BEGIN EDITED*

Actually I did test this out twice last week on different servers. Both times I saw a file was incomplete, I fxped it manually, reversing the order of Flashfxp's commands from RETR->STOR to STOR->RETR, and both times I got a complete file.

[bigstar]

This occurs when alternative FXP is being used. When the the alternative FXP option was first introduced we discovered that sending STOR prior to RETR failed 99% of the time. This problem could of been specific to the ftp servers we tested.

Perhaps this should be re-evaluated, and possibly changed.

Normally STOR is sent prior to RETR

If anyone with access to several different ftp servers would be interested in testing some code that always issued STOR before RETR, I can provide you with a special test build. Leave me a private message.

[bigstar]

Ahh I just did a test and now I see why it fails.. Let me continue doing some more tests and get back to everyone.

[bigstar]

I've come up with an experimental new method that might solve this problem when using alternative FXP with specific ftp servers. If you have this problem please contact me via Private Msg and I'll give you the location to download an special build that contains this new method.

[ErnestC]

If it is fix on the final build of version2 , it will be great....~~~~

[MxxCon]

Originally posted by ErnestC
If it is fix on the final build of version2 , it will be great....~~~~ FlashFXP 2.0 is final already.
but if that fix work out fine it'll most likely be included in the future builds

[_fuji_]

Just to add a bit more info on this topic... as it has affected myself as well...

the target ftpd has always been either g6 or bulletproof-ftpd... they are one and the same.... i receive this error sending from raidenftpd, glftpd, serv-u...

I first noticed this problem in 1.4 (can't remember the build), and noticed it in every subsequent build... and even with the 2.0 version and all release candidates...

I believe that the first few bytes of the transfer are neglected or not sent for some reason... when transferring a WinRar archive.... i cannot open it and the header seems incomplete... that and the fact that resuming the file leads to corruption is why i believe the above is true.

It only happens if transferring in the alternate-fxp mode.... or non-pasv mode. The file sizes transferred were 15,000,000 5,000,000 and 1.44 mb (zip files).

I am behind a linksys router, am the dmz host. The target ftpd was always behind a router or firewall of some sort... it also appears that for the source ftpd, it does not matter whether a firewall or router was used as the corruption happened regardless...

Your findings may be different, but that is how this bug affects me... hope any of this info helps... :)

on a totally unrelated note.... i thought this only happened to me lol :)

[MidKnight]

This has seemed to be fixed, you'll have to contact Bigstar about it