Issue with (some) Symbolic Links - unable to change to the directory

[Daniel]

I noticed that there were already several tickets opened with respect to symbolic links, and many of these have been closed, or dismissed but I am having an issue accessing 'symbolic links' within FileZila, specifically I cannot change to the symbolic directory.

The remote server is linux, and in my setup I have created several links to other directories. For example: public_html/bla/bla/bla/images -> /public_html/images. The problem is, if I click on public_html/bla/bla/bla/images it gives me directory error. However, I can access public_html/images with out an issue and via an SSH I can use the CD command to access public_html/bla/bla/bla/images also without an issue.

Now, not every symbolic link is giving me an issue. If the symbolic link, points to another path within the same directory such as, (public_html/logfiles -> public_html/logs/system) filezilla has no problem. However if the symbolic link points to a different path, it generates an error. I have tried this on two different sites I have with the same results.

Here is the (sterilized) output from filezilla:

Status: Retrieving directory listing...
Command: CWD /public_html/bla/bla/bla
Response: 250 OK. Current directory is /public_html/bla/bla/bla
Command: CWD download
Response: 550 Can't change directory to download: No such file or directory
Error: Failed to retrieve directory listing
Status: Starting download of /public_html/bla/bla/bla/download
Command: PORT 192,168,0,2,217,228
Response: 200 PORT command successful
Command: RETR download
Response: 550 Can't open download: No such file or directory
Error: Critical file transfer error
Status: Disconnected from server

The directory download is a symbolic link to public_html\pubdownloads.

This seems to be a new problem. I don't recall this issue with an older version of FileZilla.

[Wratko Hlavina]

I don't know if it's related, but in tickets #4490 and #7904, I noted that the standard for the MLST token for symlinks was changed from 'slink' (original RFC 3659) to 'symlink' (Errata ID 500 on the RFC), and FileZilla didn't recognize the newer syntax, causing various issues in handling of symlinks when using a more recent Unix FTP server with non-Unix FTP client.

[Wratko Hlavina]

I have reviewed the current source code of FileZilla, and I believe I may have identified a bug in the handling of RFC 3659 Errata ID 500 os.unix=symlink MLST protocol.

According to the errata, the target of the symlink is sent on a second line, because of concerns for possibly embedded semicolons in filenames.

The logic in CDirectoryListingParser::ParseAsMlsd() assumes the target of a filename is on one line, with os.unix=slink. That was true prior to Errata ID 500. Following the correction to the protocol, the target is sent on a second line, and the 'entry.target' variable is left empty.

To clarify, the old protocol might look like:

type=OS.unix=slink:<TARGET>; unique=<UNIQUE-ID>[...]

The post-Errata protocol might look like:

type=OS.unix=symlink; unique=<UNIQUE-ID> [...]
type=dir; unique=<UNIQUE-ID>; <TARGET>;

[Wratko Hlavina]

On further review of source code and testing:

• The parsing of 'symlink' might not fully address the RFC/Errata recommendation, but it may be good enough: if the target isn't identified immediately during the directory listing, it is probably identified when trying to process the symlink in subsequent operations. That being said, it's possible entry.target isn't being set when it could be, on the initial directory listing, and this might be suboptimal (impact on user interface presentation).
• There does appear to be some problem in actual handling of symlinks. In particular, trying to download a directory that contains a relative symlink that points up to another directory, leads to failure; in that same setup, trying to download the symlink entry itself works. Presumably, the former tries to resolve the symlink against the local filesystem, whereas the latter asks the server to fetch the content, leasing to resolving the symlink against the server-side filesystem. This is my hypothesis to explain the observed conditions leading to failure.