Crossftp tries to upload files that other users are uploadin

[gardar]

Just noticed this.

If I try to upload a file that someone else is uploading crossftp just gives me this message
[R] 553 File is being uploaded by user2
And crossftp just stalls.

What I think it should do is to follow the rule I put in my "site overwrite rules"
I have chosen to skip the transfer if a file is the same size or smaller. So imo crossftp shouldn't stall but skip the file and move on to the next file in queue.

[alex]

What happens when you saw the "crossftp just stalls"? Is the queue item's retry increased by one, and CrossFTP try to retry the queue item after 30 seconds?

Meanwhile, will check the site overwrite rule's processing. Thanks very much for the feedback!

[gardar]

Nope, it actually doesn't retry 30 times, that' what is so wired about this. It just stops at this message and doesn't retry.

[gardar]

Any news on this?

[gardar]

Bump!
This really needs to be fixed asap!

[alex]

Sorry for the delay. Will check on this these days. Thanks.

[alex]

From the initial checking, I cannot find problem in the FXP's skip function. You need to configure the target site's FXP overwrite rules to enable them. The source site's FXP is simply ignored. Did you setup the target site's FXP rule in your environment?

[gardar]

I have a global rule that is supposed to skip all FXP and overwrite none (smaller/same/larger)...

If file already exists then it does seem to work fine and just skips that file but when another user is already uploading a file I get the message previously described and the transfer just stalls, so the rest of the queue isn't processed.
I have had this problem both with drftpd and glftpd servers.

[alex]

Thanks for the information. Can you provide the full log message, at least containing the line before the "[R] 553 File is being uploaded by user2", so that we know which command causes this problem. Thanks!

[gardar]

Sure thing.

Code: Select all

[L] Secure Site to Site FTP Transfers (not supported by all servers). [Site Manager -> Security]
[R] SSCN ON
[R] 200 SSCN:CLIENT METHOD
[L] PRET RETR /SOME/LOCATION/SOME.FILE
[L] 200 OK, will use slave1 for upcoming transfer
[L] PASV
[L] 227 Entering Passive Mode (95,211,88,41,166,58).
[R] PORT 95,211,88,41,166,58
[R] 200 PORT command successful.
[R] STOR /SOME/LOCATION/SOME.FILE
[R] 553 File is being uploaded by user2


and then it just stalls, the "elapsed time" keeps on counting and nothing else heppens, no retries, nothing.

[alex]

The latest nightly build version has been updated to address this issue. You can have a try and see.

[gardar]

The latest nightly build version has been updated to address this issue. You can have a try and see.

I'll check it out.

What's the version number of the latest nightly? When I download www.crossftp.com/crossftp_nightly.jnlp I get version 1.56a which is the same version I already have.....

[alex]

The version number has not been increased. However, new jar files should be downloaded due to the update. You can use

javaws -viewer

to launch the java web start app viewer, and choose to launch CrossFTP nightly in online mode to get the files updated.

[gardar]

The problem seems to have been fixed, but now I noticed another problem

Code: Select all

[L] Secure Site to Site FTP Transfers (not supported by all servers). [Site Manager -> Security]
[R] SSCN ON
[R] 220 SSCN:CLIENT METHOD
[L] PASV
[L] 227 Entering Passive Mode (81,15,36,143,243,78)
[R] PORT 81,15,36,143,243,78
[R] 200 FXP allowed. If you're not FXPing then set your IP to **.***.***.*** (usually in firewall settings)
[R] STOR some.file.r35
[R] 553 Requested action not taken. File exists.
[L] Requested action not taken. File exists.
[L] Reconnect in 10 seconds at attempt #3


I have a skiplist on, so files that are smaller, bigger or the same size should all be skipped.
So this file should be skipped automatically but it stays in the queue.

[alex]

Thanks for your question. This may be caused by that the exited file is uploaded during your transfer process. The directory list is loaded only when the transfer starts. I will think more about this problem and try to find a solution to address this problem.