|
PRET with drftpd and offline files
Not quite sure if this is a bug, intended behavior, or even lack of handling, so this may be a feature suggestion rather than a bug report, but i will explain. The type of error responses do however seem misplaced for this situation.
Probably best to explain using part of a log
[18:52:37] [L] TYPE I
[18:52:37] [L] 200 Command okay
[18:52:37] [L] PRET RETR js42.dat
[18:52:38] [L] 530 No transfer-slave(s) available
[18:52:38] [L] SSCN ON
[18:52:38] [L] 220 SSCN:CLIENT METHOD
[18:52:38] [L] PASV
[18:52:38] [L] 500 You need to use a client supporting PRET (PRE Transfer) to use PASV
[18:52:38] Secure site to site transfers not supported by this ftp server
[18:52:38] [R] Transfer Failed!
[18:52:38] Server Error, Aborted
Basically, the file that flashfxp attempted to transfer for on a drftpd slave that went offline (so file is not currently availible). From my admitedly limited understanding of ftp rfc, 530 seems to be the correct numeric to issue from the ftpd. However flashfxp seems to mishandle or ignore it and continue which of corse results in the 500 and failed fxp.
I guess if its not a mishandling or bug, then my suggestion would be for flashfxp to do one of the following.
- Stop with the current file transfer attempt on reciept of the 530 after PRET RETR, mark the file as failed, echo a unique error message relative to the issue and move on to the next file.
- Continue acting as it currently does in reciept of the 530, then mark the file failed on reciept of the 500 indicating error, echo unique error message (not sure if this way would be wise as im not sure where else this numeric could be used after a PASV and then instead issue a PORT to correct the method and suceed), then of corse move on to the next file.
In both cases i guess the purpose is to echo a more relative error message and for the entire queue not to stop as it currently does. Currently the first failure like this will cause the entire queue to stop unnecersarily. Multi slave drftpd servers would allow some other files (on different slaves) in queue to transfer fine, and you may also have other queue items from different sites which would have no problem transfering either.
Windows 2000 Professional, DrFTPD server, tested with both 1184 and last final.
Edit: I remember seeing something in the changelog about flashfxp moving onto the site under some circumstances of failure (maybe server offline), this doesnt seem to be one of them.
Also, would i be correct in assuming that in other circumstances resulting in a "Secure site to site transfers not supported by this ftp server" error that flashfxp would react the same and not move onto the next file (or indeed the next server in queue).
|
