New SMARTFTP version upload loop issues or feature?

hello,


I have used smartftp to upload files before and without problem , but now I seem to have a problems with the new beta version and 2.0.998(might be the beta vers. i have been going back in forth).I have been wanting to purchase the program but bumping into an issue like this gives me doubt.

My intial problem started when I noticed a 2.89 gig files transfering, at an upload speed of 60 KB/sec, for 3 days. Total transfered output shown in status bar equalled 13gigs. The actual file size on the ftp server was only 1 or so gigs. I also noticed every time the file was about to complete the trasnfer, the upload would loop back to 1 gig or so, and continue uploading. Hence the 13 gig trasnfer total shown in the status bar.

Not wanting to reproduce the time-consuming large size transfer issue(i ended up using another program which i do not want to promote because i beilieve smartftp is the better choice and can do it), i started transfering my smaller files and bumped into another issue.

When tranfering a 35 KB txt file, the trasnfer completes,unfortunately, we still need to press refresh to view it in the remote directory view pane , however i do no think that is the issue. In the transfer queue under the status column a loop occurs involving the pretransfer and waiting to retry. It remains in the loop even though the file has transfered succesfully.

This finally led me to a File Exist issue setting, which
seems to be the current problem. Using the default settings of:
1) If destination size=smaller and time= Equal and trasnfer= no matter then resume
2) If destination size=smaller and time= Recent and trasnfer= no matter then resume
3) If destination size=Equal and time= Equal and trasnfer= no matter then skip
4) If destination size=Equal and time= Newer and trasnfer= no matter then skip

Default action is overwrite.

The problem occurs with this default setting.

If i choose a default of "skip", it removes it off the transfer queue. But this setting may skip valid files, so i added even more generalrules, such as

5)If destination size=Equal and time= no matter and transfer= no matter then skip
6)If destination size=Equal and time= no matter and transfer= upload then skip

But "skip" only worked


Looking into the forum i noticed smartftp has incorporated some new types of upload verification methods. These new methods require an ftp server that can return size and date information(i am probably wrong) but whatever the case my network storage unit, a bufallo teraserver, ftp services has extremely limited configuration settings for its ftp service.

I beileve this is related to the server side setup of the ftp service but like i said the ftp server has limited ftp settings and i am hoping SMARTFTP can help.

I believe a fix to this issue would remedy both my problems. This is my first attempt to use the Smartftp support services and hope it its as good as the program itself.

Here is my log file during the loop, which does seem to indicate a loop issue related to the "file size match", and also supports Smartftp's reason of needing an ftp server with a compatible file-size reporting configuration option. I would of liked to continue this thread in premiuim support since their is a related topic, but before i purchase the program i need a fix or work around.

I can accept the previuos smartftp versions because my backup error rate was almost zero.Please find a work around.

[23:13:42] Connecting to 10.10.2.3 Port: 8021
[23:13:42] Connected to 10.10.2.3.
[23:13:42] 220 STORAGE FTP server ready
[23:13:42] USER anonymous
[23:13:42] 331 Guest login ok, send your complete e-mail address as password.
[23:13:42] PASS (hidden)
[23:13:43] 230 Guest login ok, access restrictions apply.
[23:13:43] SYST
[23:13:43] 215 UNIX Type: L8
[23:13:43] Detected Server Type: UNIX
[23:13:43] FEAT
[23:13:43] 500 'FEAT': command not understood.
[23:13:43] TYPE I
[23:13:43] 200 Type set to I.
[23:13:43] REST 0
[23:13:43] 350 Restarting at 0. Send STORE or RETRIEVE to initiate transfer.
[23:13:43] PWD
[23:13:43] 257 "/" is current directory.
[23:13:43] CWD /elton/new virtual pc
[23:13:43] 250 CWD command successful.
[23:13:43] PWD
[23:13:43] 257 "/elton/new virtual pc" is current directory.
[23:13:43] Remote file exist check: "password.txt".
[23:13:43] SIZE password.txt
[23:13:43] 213 0
[23:13:43] MDTM password.txt
[23:13:43] 213 20060918141325
[23:13:43] Source File: Size=35, SizeUnit=Byte, Time=2006-09-14T12:58:07, TimeFormat=Exact
[23:13:43] Destination File: Size=0, SizeUnit=Byte, Time=2006-09-18T14:13:25, TimeFormat=Exact
[23:13:43] No rule matched. Default Action="Overwrite".
[23:13:43] PASV
[23:13:43] 227 Entering Passive Mode (10,10,2,3,16,179)
[23:13:43] Opening data connection to 10.10.2.3 Port: 4275
[23:13:43] STOR password.txt
[23:13:43] 150 Opening BINARY mode data connection for password.txt.
[23:13:43] 35 bytes transferred. (1.06 KB/s) (32 ms)
[23:13:43] 226 Transfer complete.
[23:13:43] MDTM 20060914125807 password.txt
[23:13:43] 550 20060914125807 password.txt: No such file or directory.
[23:13:43] SIZE password.txt
[23:13:43] 213 0
[23:13:43] File size mismatch.

Thanks

L10Elton

I forgot to mention, I did delete the files on the ftp server and the transfer queue, then disabled/reenabled the ftp server, and rebooted the local computer. Same problem. I once also did this with my larger file . This information leads me to believe that it is a problem that affects both resumed and new trasnfers. Also caching was removed from client (server does not have an option that i know of)Unfortunately it works with most files but not my .txt(1KB) and .vhd(3GB) . It has worked with other vhd and txt files.
I believe someone suggested using direct transfer but that defeats the prupose of the resume feature, is that not correct? Is there any way to turn off this new featue and restore previuos version upload functionality?

I am transfering over 100 files with sizes ranging from 1 KB to 12 gigs. Any help would be great.

Thanks

The FTP server on the buffalo device is is buggy and returns the wrong size in the SIZE reply:
[23:13:43] STOR password.txt
[23:13:43] 150 Opening BINARY mode data connection for password.txt.
[23:13:43] 35 bytes transferred. (1.06 KB/s) (32 ms)
[23:13:43] 226 Transfer complete.
[23:13:43] SIZE password.txt
[23:13:43] 213 0


This results in the file being transferred until the max retry count is reached.

Try to update your buffalo device with the latest available firmware:.
http://www.buffalotech.com/support/downloads.php

If the problem persists you may want to report the SIZE bug to buffalo.

Regards,
-Mat
SmartFTP

>About the statement "This results in the file being transferred until the max retry count is reached",
You can try to set the "Max Retry" value in the Menu: Tools->Settings "Queue" dialog to 1. If the queue should processes the item 2 items (1st try + 1 retry) we will find a solution which reduces this to a single try.

BTW: Please let us know if the new firmware fixes the problem. Also if you hear anything from Buffalo please share it with us ;-) Thanks.

Regards,
-Mat

Thanks Mat,

I have the latest firmware,2.03, for the HS-DTGL/R5 2TB storage unit. The technician said he would pass it on to R&E. Not too impressive but it is relatively new.

About setting the queue to 1, results in a status of "fail". This is better than the transfer queue file exist rule default action of "skip", which may skip valid files.

If there is an update in the future please let me know.

Thanks




>About the statement "This results in the file being transferred until the max retry count is reached",
You can try to set the "Max Retry" value in the Menu: Tools->Settings "Queue" dialog to 1. If the queue should processes the item 2 items (1st try + 1 retry) we will find a solution which reduces this to a single try.

BTW: Please let us know if the new firmware fixes the problem. Also if you hear anything from Buffalo please share it with us ;-) Thanks.

Regards,
-Mat

Even though i called them, this is my email response. This is my most recent results to my email attempt to resolve my issue with the ftp server on a buffalo storage unit:
***************************************************************************************
Thank you for the reply,



Are ftp files cached in any way, and if so, can I clear the cache. I mentioned smartftp in ther previous email, it seems with another ftp client, coreftp, the ftp resume function client log reported that the ftp buffalo returns a zero byte size , much like the smartftp client log. I have both log files if you need it. I have even deleted the files from ftp server, and removed cache from the ftp client(cannot find a way to remove ftp cache from server). Even disabling/enabling the ftp buffalo server. With the same files failing. Everytime i upload random files, they fail to upload and continue uploading because the file size the ftp server report to the ftp client log is zero(note: remote directory list pane does show a size greater than zero). Again, even in the remote browser directory pane list(not the log file) of both ftp clients show a size greater than zero exists. It is just the log file that shows mdtm(file created date is equal) and even correct file size check of local ftp client, but then shows an incorrect and zero file size of the remote client. I believe this cause a REST command on ftp clients at the same byte value everytime. I am new at this buffalo ftp server function. Is their email support in United States or any other fast support service. Please let me know if I can provide any information to better resolve this problem.


Funny part is when it fails, the file usually still works but not always.


Thanks












Customer Reference Number: 37015





Dear Customer,



Firmware 2.03 is still the latest version for the TeraStation HomeServer. There is no update available at the moment.



Regards,



Buffalo Technology Helpdesk,

---------------------------------------------------------------


--------------------------------------------------------------




--------------------------------------------------------------------------------





Hello,

We just purchased an HS-DTGL/R5 Series, 2TB storage unit

It seems SMARTFTP, an ftp client, and your ftp service does not report the same file size thus causing errors with resume features with clients that check file size. I do not want to put the blame on anyone but will a firmware update from 2.03 to the newest work.



And how do I perform such an update if I should proceed with this course of action.

oh yeah the guy added the ftp server was samba based, which mens nothig to me. hopefully iy helps someone else.