Bug in UTF8 support

Hello ...

The RFC isn't clear whether the feature is enabled if the UTF-8 string is found in the FEAT response. All it says is that the server supports it. If you look at other commands which are announced in the FEAT reply you will notice that it doesn't mean that they are automatically enabled by default. Also why should the server (with sending the UTF8 string in the FEAT reply) assume that the FTP client supports/uses UTF8?
ProFTPD should, as any other FTP server which supports UTF-8, implement the OPTS command to explicitly enable/disable it.

Regards,
-Mat

To force UTF8 in SmartFTP go to the Transfer settings and set the Default Code Page option to UTF8.

Regards,
-Mat

The main reason for the UTF8 option is the following:
The server doesn't know if the client sends a UTF8 string or a DBCS string (e.g. for Asian languages). The same thing applies to the client.

I just added a workaround for proftpd. It will be in the next public beta. Do you know if any other FTP server products expose the same behavior (no OPTS UTF8 and UTF8 enabled by default)?

Regards,
-Mat

vsftpd sends file names and folder names in the format they are stored; if the FS uses UTF8 vsftpd sends UTF8 without sending UTF8 during FEAT. There's a patch currently in the works that adds an option to the config file to send UTF8. (no mention of OPTS UTF8 ON as it's not in the RFC)

Hello ..

The latest version of SmartFTP now uses UTF8 if it sees the UTF8 string in the FEAT reply from the server. Nevertheless it still sends the OPTS UTF8 ON command but it doesn't check the reply.

But there is still a bug in propftpd and UTF8. It does not send everything UTF8 encoded in the reply. E.g. try to create a folder named ä on the file system over a terminal (not FTP). Then check the FTP raw directory listing and you will notice that the ä is not UTF8 encoded as it should.

Regards,
Mat