[JMM]

I've been experiencing major reliability problems with SmartFTP.

The problem that I need some answers about right now is SmartFTP's failure to reliably prompt for a decision (Overwrite / Skip / Abort) when uploading a file that already exists on the server. I never had this problem until I upgraded to a newer version a couple months ago in hopes of fixing a different reliability problem that I had become aware of.

When I drag a file from the local browser to the remote window, SmartFTP often reports the following error and unconditionally overwrites the file without prompting me:
"550 SIZE: Operation not permitted"

Sometimes it inexplicably switches from working (prompting me) to not working. Earlier today it was working, then stopped (all the while accessing the same server). Right now it has stopped working entirely -- crippling my ability to work. The problem has occurred with a variety of FTP servers.

This behavior -- automatically overwriting files on the server -- is totally unacceptable.

Registration Data:
ID: 400009979
User: Jesse McCarthy


System Info:
+- System -----------------------------
Microsoft Windows XP Home
Service Pack 2 (Build 2600)

CPU Speed : 2998 MHz
Total Memory : 1047788 KB
Free Memory : 679204 KB

+- SmartFTP ---------------------------
Version : 1.5.991.24
Time Stamp : 2005-12-15 22:44:57

+- Application DLL --------------------
Controls.dll : 1.6.991.24
sfFTPLib.dll : 1.5.7.5
SmartHook.dll : 1.0.2.1

+- Language ---------------------------
SmartFTP.exe : 1.5.991.24

+- System DLL -------------------------
shell32.dll : 6.00.2900.2763 (xpsp_sp2_gdr.050922-1642)
shlwapi.dll : 6.00.2900.2781 (xpsp_sp2_gdr.051020-1730)
comctl32.dll : 6.0 (xpsp_sp2_rtm.040803-2158)
riched20.dll : 5.30.23.1221
schannel.dll : 5.1.2600.2180 (xpsp_sp2_rtm.040803-2158)

+- Internet Explorer ------------------
Version : 6.0.2900.2180

+- Winsock ----------------------------
Winsock : 2.2



The following is an example log that corresponds to me connecting to a server, changing directory twice, then uploading a file that already exists on the server. The file was overwritten without me ever being prompted. The same thing keeps happening even after closing SmartFTP and rebooting.

SmartFTP v1.5.991.24
Resolving host name "XXX.X.XX.X"
Connecting to XXX.X.XX.X Port: 21
Connected to XXX.X.XX.X.
220 ProFTPD 1.3.0rc2 Server (Main FTP Server) [XXX.X.XX.X]
USER username
331 Password required for username.
PASS (hidden)
230 User username logged in.
SYST
215 UNIX Type: L8
FEAT
211-Features:
MDTM
REST STREAM
SIZE
211 End
PWD
257 "/" is current directory.
CWD /
250 CWD command successful
PWD
257 "/" is current directory.
TYPE A
200 Type set to A
PASV
227 Entering Passive Mode (XXX,X,XX,X,8,194).
Opening data connection to XXX.X.XX.X Port: 2242
LIST -laL
150 Opening ASCII mode data connection for file list
1449 bytes transferred. (30.1 KB/s) (47 ms)
226 Transfer complete.
CWD /internal.domain.com
250 CWD command successful
PWD
257 "/internal.domain.com" is current directory.
PASV
227 Entering Passive Mode (XXX,X,XX,X,8,195).
Opening data connection to XXX.X.XX.X Port: 2243
LIST -laL
150 Opening ASCII mode data connection for file list
2333 bytes transferred. (36.1 KB/s) (63 ms)
226 Transfer complete.
CWD /internal.domain.com/library
250 CWD command successful
PWD
257 "/internal.domain.com/library" is current directory.
PASV
227 Entering Passive Mode (XXX,X,XX,X,8,196).
Opening data connection to XXX.X.XX.X Port: 2244
LIST -laL
150 Opening ASCII mode data connection for file list
6888 bytes transferred. (47.7 KB/s) (141 ms)
226 Transfer complete.
Remote file exist check: 'email_list_results.php'.
SIZE email_list_results.php
550 SIZE: Operation not permitted
PASV
227 Entering Passive Mode (XXX,X,XX,X,8,200).
Opening data connection to XXX.X.XX.X Port: 2248
STOR email_list_results.php
150 Opening ASCII mode data connection for email_list_results.php
3649 bytes transferred. (57.4 KB/s) (62 ms)
226 Transfer complete.
PASV
227 Entering Passive Mode (XXX,X,XX,X,8,201).
Opening data connection to XXX.X.XX.X Port: 2249
LIST -laL
150 Opening ASCII mode data connection for file list
6888 bytes transferred. (48.0 KB/s) (140 ms)
226 Transfer complete.
Transfer successful.
NOOP
200 NOOP command successful
NOOP
200 NOOP command successful



What the hell is going on?

[Aokromes]

Hi, do you have that site on favorites? if yes, edit the favorite and check the settings at Transfer->Files->On File Exist.

[JMM]

Aokromes, on Dec 23 2005, 10:28 PM, said:

Hi, do you have that site on favorites? if yes, edit the favorite and check the settings at Transfer->Files->On File Exist.

No, I just have it in the History, and my default Transfer > Files > File Exist settings are all set to "Ask". It was working on the same server earlier today. Then it stopped and would work the 1st time after I reconnected to the site, then not work again after I chose "Overwrite" once. Then it stopped working completely.

I've experienced the problem in the past, sporadically, but thought that it was only happening when memory was running low on my system. This is the first time it's stopped working completely and won't start working again, even after rebooting and only having SmartFTP running.

[Aokromes]

Hi, can you try with the version 2.0 if it fixes your trouble? you can get it at http://www.smartftp....et/SFTPBeta.exe
For the size denied, i think it can be because server configuration, maybe they touched something on a recent server upgrade.

[JMM]

Aokromes, on Dec 24 2005, 01:52 AM, said:

Hi, can you try with the version 2.0 if it fixes your trouble? you can get it at http://www.smartftp....et/SFTPBeta.exe
For the size denied, i think it can be because server configuration, maybe they touched something on a recent server upgrade.

Sorry, no. Considering that updating to newer versions of SmartFTP tends to increase my problems, I don't see updating to a beta as the move to make.

When the problem that I described happening on that day really blew up in my face, it went from working to not working between actions that were minutes apart -- so I sincerely doubt anything changed on the server side in between. In any case, as I said, I've experienced the problem with other servers at other times.

The bottom line is that whatever SmartFTP is doing with SIZE is not working out. I need SmartFTP to reliably prompt me when I try to upload / download a file that already exists. There's no leeway there -- that's an absolutely critical function.

[Aokromes]

Well, SmartFTP 2.0 don't overwrites the 1.x version, you can test it without fear of doing something bad for you, and you can delete if it don't fixes your trouble.

[mb]

Your FTP server doesn't support or doesn't allow a basic FTP command (SIZE). Thats where the problem is coming from. We do not have any plans to write a workaround for this at the moment.

Regards,
-Mat
SmartFTP

[JMM]

mb, on Dec 26 2005, 01:27 AM, said:

Your FTP server doesn't support or doesn't allow a basic FTP command (SIZE). Thats where the problem is coming from. We do not have any plans to write a workaround for this at the moment.

Regards,
-Mat
SmartFTP

Actually, SIZE isn't a basic command and is not part of a completed standard, it's part of an expired working draft specification of extensions to FTP.

EDIT -- I acknowledge that SIZE has been commonly implemented in FTP clients / servers, but I question the wisdom of tying a critical program feature (prompt on file exist) to a nonstandard command. The problem that's come up with ProFTPD illustrates the danger of doing so.

The server that I posted the log from is a ProFTPD server and the problem apparently relates to the issue described here: ProFTPD and ASCII Transfers.

Here's an excerpt of a log from the same server demonstrating the situation:

	TYPE A
200 Type set to A
	SIZE index.php
550 SIZE: Operation not permitted
	TYPE I
200 Type set to I
	SIZE index.php
213 6657
	TYPE A
200 Type set to A
	SIZE index.php
550 SIZE: Operation not permitted
	TYPE I
200 Type set to I
	SIZE index.php
213 6657

So what can we do about this?

[mb]

Thank you for the research.

You are right that the SIZE command is not part of the RFC 959. But sticking to this RFC only would leave us with a very primitive protocol which is certainly not adequate anymore. As you pointed out, the SIZE command is implemented by proftpd, but it doesn't return any value if the transfer type is set to ASCII. This implementation is correct and makes sense. Other FTP servers ignore the transfer type and always return the size of the file if it would be transferred with the type set to binary/image.
As a result to support both scenarios the new version makes sure that the transfer type (TYPE) is set to binary/image before the SIZE command is sent to the server.

Please get the latest version from
http://www.smartftp....get/SFTPDev.exe

In addition, because ASCII transfers (TYPE A) cannot be resumed and the transfer integrity checks aren't working, I recommend you to remove all entries from the ASCII list in the Global Settings->Transfer->ASCII/Binary dialog.

-Mat
SmartFTP

[JMM]

Thank you, that appears to resolve the problem. I appreciate your attention to this issue.

mb, on Dec 29 2005, 05:12 AM, said:

In addition, because ASCII transfers (TYPE A) cannot be resumed and the transfer integrity checks aren't working, I recommend you to remove all entries from the ASCII list in the Global Settings->Transfer->ASCII/Binary dialog.

Could you elaborate on that, please? It sounds like that will cramp my style, considering that I am authoring things like HTML documents on a Windows machine and then transferring the files to *nix servers.

[eyebex]

Any good (programming) editor under Windows can handle Unix (and even Mac) style line-feeds. It is always recommended to edit files in their target system's native format and upload them in binary mode.

Also see my post here: http://www.smartftp.com/forums/index.php?s...indpost&p=31648

This post has been edited by eyebex: 04 January 2006 - 11:34 AM