joachim
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
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