false handling of file attributes in sftp protocol

[jimmyjjames]

filezilla apparently handels file attributes in the sftp protocol by parsing the "longname" of the SSH_FXP_NAME resoponse packet. since the format of the longname in sftp version 3 is not
specified and the SSH_FXP_NAME contains an ATTRS field which contains explicit attributes for each filename it would make more sence to use them instead of the longname: ​http://tools.ietf.org/html/draft-ietf-secsh-filexfer-02#section-7

furthermore filezilla parses the longname in a false way. Symbolic links have in the longname the letter "l" on the first position instead of "-" for files or "d" for directories. but filezilla shows symbolic links always as directories regardless of the target it links to, which is wrong.

[Tim Kosse]

The symbolic link handling is intentional. Symbolic links to files cannot be distinguished from symbolic links to directories. Only by trying to access the symbolic link and observing the result can this distinction be made. This is why FileZilla treats all symbolic links initially as directories.

[jimmyjjames]

Yes, i guess it is true as long as filezilla parses the longname to get the attributes. But that is exactly the problem. Filezilla could simply use the SSH_FXP_STAT packet to get the attributes and look at the permissions field (see S_IFLNK, S_IFREG, and S_IFDIR constants in linux). That is by the way how all other sftp client programms do it.

[Andreas]

Although it might seem uncritical, parsing the longname is just the wrong way to go. To quote the rfc ​https://tools.ietf.org/html/draft-ietf-secsh-filexfer-02, page 22:

The format of the `longname' field is unspecified by this protocol.
It MUST be suitable for use in the output of a directory listing
command (in fact, the recommended operation for a directory listing
command is to simply display this data). However, clients SHOULD NOT
attempt to parse the longname field for file attributes; they SHOULD
use the attrs field instead.