SmartFTP constructs invalid absolute path with some servers

This had been reported years ago by others and was then dismissed by blaming the problem on "poor server implementation". I would argue, however, that SmartFTP is not doing what it should, contrary to what was claimed in the old thread: https://www.smartftp.com/forums/director ... t7210.html

We are dealing with a third-party FTP server for a proprietary embedded operating system that behaves similar to the Xbox server described in the thread quoted above. In response to the PWD command this server returns a path of the form "C:/somepath". When clicking on directories SmartFTP attempts to construct an absolute path and ends up with something like /C:/somepath" which the server rejects. The problem is the additional slash at the front of the path. It is easy to blame the server for not using a more reasonable, speak UNIX-like, directory notation, but I think such a server is still in compliance with the FTP RFC. I don't see, however, how SmartFTP can justify its practice of prepending this leading slash on anything in the RFC. If I'm wrong, please quote a relevant paragraph in the RFC and I'll shut up.

If SmartFTP had constructed the absolute path by appending relative paths at the end of a path that was returned by PWD it would have worked, and of course, relative paths would work fine too. But blindly prepending a slash doesn't work with these servers.

Is there a reason why this extra slash is prepended? In other words, what would break if this was not done? More typical servers will return paths that start with a slash in response to PWD anyway, so these don't need an extra slash either.

Note, that your competitor WS_FTP works fine with the server in question, so we can just recommend that product to our customers, but we would of course prefer if SmartFTP worked too.

Thanks,

Joachim

Please post the log of your FTP session including a few CWD, PWD commands.

There are so many FTP server implementations available but most of them are not following the RFC correctly. Therefore FTP clients are full of workarounds for each of one of them. e.g. One doesn't use a / but claiming the SYST is UNIX, one doesn't output the time correctly, SIZE is wrong or not supported before a listing, etc. To write a workaround for such situations we need a complete log of the FTP session. This will help us to identify the server software and adjust the internal parameters accordingly.

We promote FTP servers which are following the RFC, properly written, well maintained and which meet today's software standards. All others only make the FTP world more complicated for everyone especially for the end users.

Thanks
-Mat

OK, I downloaded a copy of your latest beta (I'm not normally using SmartFTP, was just reporting what our customer told us). The log shows exactly what I described, i.e. the server reports the current directory in response to PWD as "C:/" and SmartFTP then adds a slash in front of this and requests a change to directory "/C:/" which is invalid and rejected:

SmartFTP v1.5.990.14
Resolving host name "na158"
Connecting to 205.159.216.158 Port: 21
Connected to na158.
220 NetAcquire FTP Server ready
USER ftp
331 User name okay, need password.
PASS (hidden)
230 SuperUser logged in, proceed.
SYST
215 TNT Embedded ToolSuite system type.
FEAT
500 Syntax error, command unrecognized.
TYPE I
200 Command okay.
REST 0
202 Command not implemented, superfluous at this site.
PWD
257 "C:/" is the current directory.
CWD /C:/
550 Requested action not taken: Not a directory

If I use Change Folder and enter an absolute path in Unix format, e.g. "/foo", SmartFTP uses that path unchanged and it works:

CWD /foo
250 Directory changed to "C:/FOO".
PWD
257 "C:/FOO" is the current directory.

But clicking on a sub directory again results in an error:

CWD /C:/FOO/BAR
550 Requested action not taken: Not a directory

This is because SmartFTP doesn't use the relative path (which would have worked) and instead puts the reported current directory in front (which would still be OK) *AND* adds a leading slash in front. This last point (adding a slash in front of what PWD returns) is the problem. In compliance with the FTP RFC the server responds to PWD with a string that can be used without problem to navigate to this directory, but SmartFTP insists on modifying the returned path by adding a slash in front. My position is that this behaviour of SmartFTP has no justification from any RFC I have seen.

Again, I have to ask why SmartFTP needs to add this extra slash? On systems that use UNIX-style paths PWD will already return a string that starts with a slash, so SmartFTP should never need to add it explicitly.

Thanks,

Joachim

Navigating directories now seems to work, although there is an initial failure when first connecting. For some reason file downloads don't work. It seems to do a CWD without path:

CWD
500 Syntax error, command unrecognized.
Transfer failed.

This happens when using drag-and-drop or the Commands/Download/Direct menu item.

Joachim

Please post the complete log. Keep it in mind for the future.

As I don't have access to the proprietary FTP server software it's not easy to debug. Please provide more information about the failed direct downloads.

I think I know where the problem is coming from with the initial CWD command. It should be CWD / because you specified an initial directory in the address bar or in the favorite item properties. Otherwise the CWD command wouldn't be sent.

-Mat

Here is the complete log:

[20051004 20:47:22] Log opened
[20051004 20:47:22] SmartFTP v1.5.990.16
[20051004 20:47:22] Resolving host name "na158"
[20051004 20:47:22] Connecting to 205.159.216.158 Port: 21
[20051004 20:47:22] Connected to na158.
[20051004 20:47:22] 220 NetAcquire FTP Server ready
[20051004 20:47:22] USER ftp
[20051004 20:47:22] 331 User name okay, need password.
[20051004 20:47:22] PASS (hidden)
[20051004 20:47:22] 230 SuperUser logged in, proceed.
[20051004 20:47:22] SYST
[20051004 20:47:22] 215 TNT Embedded ToolSuite system type.
[20051004 20:47:22] FEAT
[20051004 20:47:22] 500 Syntax error, command unrecognized.
[20051004 20:47:22] TYPE I
[20051004 20:47:22] 200 Command okay.
[20051004 20:47:22] REST 0
[20051004 20:47:22] 202 Command not implemented, superfluous at this site.
[20051004 20:47:22] PWD
[20051004 20:47:22] 257 "C:/" is the current directory.
[20051004 20:47:22] CWD C:/
[20051004 20:47:22] 250 Directory changed to "C:/".
[20051004 20:47:22] PWD
[20051004 20:47:22] 257 "C:/" is the current directory.
[20051004 20:47:31] CWD
[20051004 20:47:31] 500 Syntax error, command unrecognized.
[20051004 20:47:31] Transfer failed.

The last three lines are the result of trying to download a file in the root directory with drag-and-drop. Same happens in other directories too.

You were right about the first CWD failure in my previous post. This happened because my favourites entry had the invalid "/C:/" entry in it, which the previous beta version must have added without me realizing it.

Joachim

Hm .. I'm not sure if the latest beta version fixes it, but I would appreciate if you could give it a try.

Thanks
-Mat

Thanks Mat,

This seems to work now. I will tell our customer that he can try using your latest beta build. I'm impressed by your quick response to this issue.

Regards,

Joachim