Filezilla client has troubles with Novell FTP, due to "//" handling

[Darcy]

This is a resurrection of client bug #790 (which was closed due to inactivity). I was not the person who filed that originally. I am the senior FTP support specialist with Novell Worldwide Support. I will base this report description on the older one, but will update it:

Novell's FTP server software allows one to access the files on ANY
Novell file server in their directory tree, using this syntax:

cwd server/volume/dir/subdir

And some Novell FTP servers will even let someone's home directory be in that format.

This feature is sometimes referred to at Novell as a "FTP Gateway" where one FTP server can give users access to an entire Directory Tree of servers. We also call it our "remote server" feature.

Novell FTP server is (to my knowledge) the only FTP server in the world to provide this feature. So admittedly, this effects only a subset of your user base.

But when FileZilla (3.7.3) sees such a syntax (through pwd output), or when you enter a path into Filezilla's "remote site" field, such as "server1/volume1/path/" Filezilla often strips off the first '/' character. This seems to especially be a problem when using the QuickConnect button to start a session, rather than Site Manager. But I've had customers complain of it even when using Site Manager.

Because of this, anytime Filezille wants to reference the absolute path in a command, it references "/server1/..." instead of "server1/...". This difference causes the Novell FTP server to look for a local path (local to the FTP server) called "/server1/..." rather than access the separate host machine "server1". And thereby, it returns a '550 invalid path' error, or similar.

I would be happy to work closely with you to pursue this issue. Many of our common customer would benefit from having Filezilla know that (at least with Novell servers) it should preserve double-slash syntax rather than strip it off.

Also, please note that not every Novell FTP server would be using this syntax. So it wouldn't be as simple as saying, "build every absolute path for Novell beginning with a double slash." Instead, it will be a matter of looking at what syntax is given (via PWD or via user input) and if it begins with "" preserve that rather than strip it to "/".

I will quote the following from the older bug as well, though I have not verified all of this:

---

Another FTP client, NCFtp (www.ncftp.com) had the same issue a
few versions back, but has since been fixed. WS_FTP on Windows,
Fetch and Transmit on Mac OSX, and the command line FTP
program on any Mac/Linux/Windows system all work correctly with
this functionality and do not have this issue.

---

That is not to say that all those clients fully understand and automatically correctly use the "" syntax. But in many cases, clients don't insist on referencing the absolute path as much as Filezilla does, so they will often "just work" where Filezilla doesn't.

Here's a log of a Filezilla FTP session to a Novell FTP server, demonstrating this:

Status: Connecting to 151.155.214.77:21...
Status: Connection established, waiting for welcome message...
Response: 220-Welcome to Pure-FTPd.
Response: 220-You are user number 1 of 1000 allowed.
Response: 220-This is a private system - No anonymous login
Response: 220-IPv6 connections are also welcome on this server.
Response: 220 You will be disconnected after 15 minutes of inactivity.
Command: USER admin
Response: 331 User admin OK. Password required
Command: PASS *
Response: 230-User admin has group access to: admingroup
Response: 230 OK. Current directory is dp-sles11sp2VOL1\sub2
Command: OPTS UTF8 ON
Response: 200 OK, UTF-8 enabled
Status: Connected
Status: Retrieving directory listing...
Command: PWD
Response: 257 "dp-sles11sp2/VOL1\sub2" is your current location
Status: Directory listing successful
Status: Connecting to 151.155.214.77:21...
Status: Connection established, waiting for welcome message...
Response: 220-Welcome to Pure-FTPd.
Response: 220-You are user number 2 of 1000 allowed.
Response: 220-This is a private system - No anonymous login
Response: 220-IPv6 connections are also welcome on this server.
Response: 220 You will be disconnected after 15 minutes of inactivity.
Command: USER admin
Response: 331 User admin OK. Password required
Command: PASS *
Response: 230-User admin has group access to: admingroup
Response: 230 OK. Current directory is dp-sles11sp2VOL1\sub2
Command: OPTS UTF8 ON
Response: 200 OK, UTF-8 enabled
Status: Connected
Status: Starting upload of C:\Users\dpartrid\Desktop\add5.pdf
Command: CWD /dp-sles11sp2/VOL1\sub2
Response: 550 Can't change directory to /dp-sles11sp2/VOL1/sub2: No such file or directory
Command: CWD /dp-sles11sp2
Response: 550 Can't change directory to /dp-sles11sp2: No such file or directory
Command: CWD /
Response: 250 OK. Current directory is /
Command: MKD dp-sles11sp2
Response: 550 Can't create directory: Permission denied
Command: MKD /dp-sles11sp2/VOL1\sub2
Response: 550 Can't create directory: No such file or directory
Command: CWD /dp-sles11sp2/VOL1\sub2
Response: 550 Can't change directory to /dp-sles11sp2/VOL1/sub2: No such file or directory
Command: SIZE /dp-sles11sp2/VOL1\sub2/add5.pdf
Response: 550 Can't check for file existence

[Darcy]

Additional data about the log shown in the initial description:

This is a log of a quick connection session, where it logged in fine, and the session was put in home directory dp-sles11sp2/VOL1/sub2. Then I attempted to upload file "add5.pdf". The rest of the commands shown were all automatically generated by Filezilla in it's attempts to upload that file, or to auto-recover from the failures happening. Filezilla kept trying to use absolute paths beginning with /dp-sles11sp2 (which fail) instead of dp-sles11sp2 (which would have succeeded).

I have also seen other Filezilla client installations (diff versions?) where it attempted "STOR /server1/vol1/path/file" which failed, when it could have succeeded with either:

STOR server1/vol1/path/file
or simply with:
STOR file
(This would work since the current directory was already at the desired path. The redundancy of using absolute path isn't usually necessary.)

[Tim Kosse]

Do you still experience this issue if upgrading to FTP server software that adheres to the TVFS specifications from RFC 3659?