Unable to transfer multiple files

Hi, after experiencing the latest unable to connect issue with SmartFTP 2.0.0999, I updated to 2.0.1000 and the issue was resolved. However, I began to notice a different problem occuring.

When I drag and drop multiple edited files from Local to Remote directory, I get

[16:45:18] File size mismatch.

during the transfer process, then

[16:45:18] Transfer failed.

at the end. Only the first file successfully transfers. Checking the transferred file, the data is all correct, indicating a successful transfer. Why am I now unable to transfer multiple files through drag and drop?

Hello ..

Please post the complete log. The server might send the wrong SIZE command after the transfer.

Regards,
-Mat

Okay sure, here is the log which posts after I began the transfer using a single file. Please note the two lines I begin with >, I don't recall those lines being there previously. They are in dark red text. The file I transferred is in actuality moved over, and the contents show correctly even though the log claims the transfer failed. This only occurs when the file I transfer from the local is a different file size than the file on the remote. When I move multiple files, only the first file is really moved, and shows the same "file size mismatch" and "transfer failed" error messages.

[10:21:12] 213 9283
[10:21:13] Remote file exist check: "hc_cc.asp".
[10:21:13] SIZE hc_cc.asp
[10:21:13] 213 48782
[10:21:13] MDTM hc_cc.asp
[10:21:13] 213 20061118005603
[10:21:13] PASV
[10:21:13] 227 Entering Passive Mode (216,246,42,180,7,133).
[10:21:13] Opening data connection to 216.246.42.180 Port: 1925
[10:21:13] STOR hc_cc.asp
[10:21:13] 125 Data connection already open; Transfer starting.
[10:21:14] 48770 bytes transferred. (56.4 KB/s) (843 ms)
[10:21:14] 226 Transfer complete.
[10:21:14] MDTM 20061120182040 hc_cc.asp
[10:21:14] 550 20061120182040 hc_cc.asp: The system cannot find the file specified.
[10:21:14] SIZE hc_cc.asp
[10:21:14] 213 48782
>[10:21:14] File size mismatch.
[10:21:14] TYPE A
[10:21:14] 200 Type set to A.
[10:21:14] PASV
[10:21:15] 227 Entering Passive Mode (216,246,42,180,7,134).
[10:21:15] Opening data connection to 216.246.42.180 Port: 1926
[10:21:15] LIST -aL
[10:21:15] 125 Data connection already open; Transfer starting.
[10:21:15] 6448 bytes transferred. (25.1 KB/s) (250 ms)
[10:21:15] 226 Transfer complete.
>[10:21:15] Transfer failed.

Hello ..

Use the transfer queue for your transfers. It will automatically retry the broken/failed transfers. Please see the tutorials at
https://www.smartftp.com/support/howto

Regards,
-Mat

Thank you for your help. the Transfer Queue has the same problem occuring. The first file in the transfer queue list will just keep sending until I stop it, I assume this is because Smartftp is reporting the file size mismatch and transfer failed still, but I cannot be certain because it will not show in the log with transfer queue. Anyway, I don't believe using transfer queue instead of drag and drop really solves the problem, it is only using alternate means. Does this mean the problem I am experiencing happens to everybody else as well? It is wierd, because I did not have this problem with an earlier version, and my SmartFTP at home using an older version has never had this problem.

The server seems to report the wrong size in the SIZE reply. You may want to ask the administrator of the server to update the FTP server software.

Regards,
-Mat

I believe you are absolutely correct. Problem is, the web hosting service uses the latest FTP server software(I verified this to be true). This isn't the first time I've had problems with the software, so I am not very surprised. Is there a method in which I can set SmartFTP to transfer the next file even though the server claims wrong file size?

When transfering files with the direct transfer method (not with the transfer queue) you can enable the "Continue On Error" option in the Settings->Transfer. Once the option is enabled errors like this will be ignored.

Regards,
-Mat

Okay, the Continue on Error option works fine. Thank you very much for your help on this.