Filezilla SFTP Client see folders as regular files

[Adrian Iurca]

I am using a customized SFTP Server, which works with SFTP version 3.
The connection process is working good, also the init process:
Filezilla client send SSH_FXP_INIT with version 3 to my_sftp_server( runs on OpenSUSE 42.3 ), and my_sftp_server respond with version 3.

But when listing in root directory( '/' ) is made the directories from root directory are seen as regular files( the folders are 'Hold' and 'Print' ).

If i write on Remote Site panel explicitly the folder name then then i can access the folder.

Here are traces in Verbose mode:

Status: Connecting to gjdev242.spr...
Trace: CControlSocket::SendNextCommand()
Trace: CSftpDeleteOpData::Send() in state 0
Trace: Going to execute C:\Program Files\FileZilla FTP Client\fzsftp.exe
Response: fzSftp started, protocol_version=8
Trace: CSftpDeleteOpData::ParseResponse() in state 0
Trace: CControlSocket::SendNextCommand()
Trace: CSftpDeleteOpData::Send() in state 3
Command: open "aiurca@…" 22
Trace: Connecting to 172.27.126.242 port 22
Trace: We claim version: SSH-2.0-FileZilla_3.37.4
Trace: Server version: SSH-2.0-OpenSSH_7.2
Trace: Using SSH protocol version 2
Trace: Doing ECDH key exchange with curve Curve25519 and hash SHA-256
Trace: Server also has ecdsa-sha2-nistp256/ssh-dss/ssh-rsa host keys, but we don't know any of them
Trace: Host key fingerprint is:
Trace: ssh-ed25519 256 45:2e:1c:66:89:3c:4c:75:63:11:20:6f:a8:9f:aa:83 C2WUhxiha662r7sZPzjr1ns39x9j1JQkkwCbcsDRo+8=
Trace: Initialised AES-256 GCM client->server encryption
Trace: Initialised AES256 GCM client->server MAC algorithm (in ETM mode) (required by cipher)
Trace: Initialised AES-256 GCM server->client encryption
Trace: Initialised AES256 GCM server->client MAC algorithm (in ETM mode) (required by cipher)
Trace: Attempting keyboard-interactive authentication
Trace: Using keyboard-interactive authentication. inst_len: 0, num_prompts: 1
Command: Pass:
Trace: Access granted
Trace: Opening session as main channel
Trace: Opened main channel
Trace: Started a shell/command
Status: Connected to gjdev242.spr
Trace: CSftpDeleteOpData::ParseResponse() in state 3
Trace: CControlSocket::ResetOperation(0)
Trace: CSftpDeleteOpData::Reset(0) in state 3
Status: Retrieving directory listing...
Trace: CControlSocket::SendNextCommand()
Trace: CSftpListOpData::Send() in state 0
Trace: CSftpChangeDirOpData::Send() in state 0
Trace: CSftpChangeDirOpData::Send() in state 1
Command: pwd
Response: Current directory is: "/"
Trace: CSftpChangeDirOpData::ParseResponse() in state 1
Trace: CControlSocket::ResetOperation(0)
Trace: CSftpChangeDirOpData::Reset(0) in state 1
Trace: CSftpListOpData::SubcommandResult(0) in state 1
Trace: CControlSocket::SendNextCommand()
Trace: CSftpListOpData::Send() in state 2
Trace: CSftpListOpData::Send() in state 3
Command: ls
Status: Listing directory /
Trace: CSftpListOpData::ParseResponse() in state 3
Trace: CControlSocket::ResetOperation(0)
Trace: CSftpListOpData::Reset(0) in state 3
Status: Directory listing of "/" successful

[Adrian Iurca]

I wanna mention that with WinSCP sftp client works properly.

Kind regards,
Adrian Iurca

[Tim Kosse]

What's in the longname field of the SSH_FXP_NAME response for these files?

[Adrian Iurca]

In my implementation, longname field has same value with filename.

Kind regards,
Adrian Iurca

[Tim Kosse]

That's the problem, FileZilla takes the information whether a file is a directory from the longname. There's no other field in the SSH_FXP_NAME which indicates whether a file might be a directory.

[Adrian Iurca]

Hello Tim,

That is the problem, Filezilla takes information from 'longname' field. But when i have start to develop my_sftp_server, i found this chapter about 'longname': "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." . However, thank you for answering and helping me with this problem.

Kind regards,
Adrian Iurca