first store and then retrieve

[BiteMeNow]

how about this? i get awesome errors some times.

if you try first store and the file is read only then you will get faster a reply without strange messages

please correct me if i am wrong.

bye
BiteMeNow

[MxxCon]

i don't follow you

[BiteMeNow]

1. i set in the 'When File Exists." options for fxp auto-skip.
2. on the target server the file is read-only.

when i try to fxp some files from site to site and on the destination server the files already exists, flasfxp need long time to realize this and the write down a error message. (it does first retr and then store)

if i do the same with for example smartftp it first do store and then retr. anyway it will check much faster that the file already exists on the target server.

now my question is : where is here the matter? should flashfxp also do first store?

thx for reply
BiteMeNow

[Lemming]

I sometimes have problems FXPing and I believe they are caused by the RETR coming before the STOR... Files are erased instead of resumed and/or no data is transferred at all.. It might be due to strange/buggy ftp server software, but if I manually enter all commands but putting the STOR before the RETR, it works fine...

(1) TYPE I
(1) 200 Type set to I.
(2) TYPE I
(2) 200 Type set to I.
(2) PASV
(2) 227 Entering Passive Mode (1,2,3,4,107,164)
(1) PORT 1,2,3,4,107,164
(1) 200 PORT Command successful.
(1) REST 43656192
(1) 350 Restarting at 43656192 - send STORE or RETRIEVE to initiate transfer.
(1) RETR large file.dat
(1) 150 Opening BINARY mode data connection for large file.dat (93335552 bytes).
(2) REST 43656192
(2) 350 Restarting at byte offset 43656192. Send STORE or RETRIEVE to initiate transfer.
(2) STOR large file.dat
(2) 125 Ready to receive "large file.dat" . Mode STREAM Type BINARY.

Resets size on server 2 to zero and nothing is transferred


But when I manually enter following commands (same as first but different order):

(1) TYPE I
(1) 200 Type set to I.
(2) TYPE I
(2) 200 Type set to I.
(2) PASV
(2) 227 Entering Passive Mode (1,2,3,4,107,165)
(1) PORT 1,2,3,4,107,165
(1) 200 PORT Command successful.
(2) REST 43656192
(2) 350 Restarting at byte offset 43656192. Send STORE or RETRIEVE to initiate transfer.
(2) STOR large file.dat
(2) 125 Ready to receive "large file.dat" . Mode STREAM Type BINARY.
(1) REST 43656192
(1) 350 Restarting at 43656192 - send STORE or RETRIEVE to initiate transfer.
(1) RETR large file.dat
(1) 150 Opening BINARY mode data connection for large file.dat (93335552 bytes).

File is transferred correctly

[bigstar]

The order of the RETR and STOR shouldn't matter. It's better to STOR first that way you can determine if the folder is write protected or if you have permission to upload.

I believe if you enable Alternative FXP in the Site Manager RETR & STOR are reversed, but it's been so long I'm not entirely sure.

[Lemming]

Originally posted by bigstar
The order of the RETR and STOR shouldn't matter. It's better to STOR first that way you can determine if the folder is write protected or if you have permission to upload.

Yes, but flashfxp sometimes does the RETR first, as in my example...

I believe if you enable Alternative FXP in the Site Manager RETR & STOR are reversed, but it's been so long I'm not entirely sure.

I think it might too, but what if it doesn't support alternate method?

Anyway, I don't know why but there is times when I can try every combination of the alternate methods and nothing works yet when I can manually do the transfer, it works fine... And the only difference I see is the order of the STOR and the RETR...

[bigstar]

What FTP server software do both of the FTP servers use?

[Lemming]

This time it was Serv-U and WarFTPd, but it isn't only that combination that has problems, I don't think...

[bigstar]

WarFTPd has a strange issue with the STOR command when using PASV mode. STOR must be issued before the data connection is established. With site to site transfers this is not possible because the FTP server establishes the connection.

I suspect by issuing the commands manually you get around the problem.

We have no plans on adding support for WarFTPd to resolve this issue.