Uploading file with russian letter in name to ftp server result in: 1) client receive error; 2) file uploaded on server has broken name. This issue isn't specific to this ftp server, it's just result of conforming to brain-damaged RFC. And many other ftp servers have same issue. For example: http://www.smartftp.com/forums/lofiversion/index.php?t12434.html (I'm not sure how proposed solution is accurate, though - this url is just an example of same issue discussed for another ftp server). I propose to add a patch, which broke RFC-compliance, but fix this bug. I'm using it for years, and some other ftp servers also use similar patch, so there shouldn't be any troubles with it. Anyway, it should be optional (applied only when some USE-flag is set). Reproducible: Always Steps to Reproduce: 1. install twoftpd on Linux 2. try to upload from Windows file with small russian letter "ja" (which code is 255) Actual Results: error while upload; damaged file name on server (letter "ja" and 1-2 letters after it will be removed from file name) Expected Results: no error, file name on server isn't broken
Created attachment 167602 [details, diff] disable TELNET_IAC support to allow symbol with code 255 in file names
BTW, I've just converted my system from KOI8-R to UTF-8 and so I was able to test this issue on Unicode system (to check strange recommendation found on SmartFTP forum). No surprise though: when it work with Windows client (which use CP1251 encoding) filenames transferred by network using that encoding (Linux system encoding can't affect bytes sent by Windows FTP client) and so it will not work with that patch. :(
Oops, sorry, there typo: > and so it will not work with that patch should be read as: > and so it will not work withOUT that patch
as you correctly point out, the problem isn't the server, its the client. as such the client should be fixed and not the server. i will not include such a patch, but you may try pushing this to upstream. if it is accepted there, i'll package it up. thanks. kind regards Thilo
bug in client
this isn't "bug in client". this is bug in RFC. clients can't be fixed, because there no way to work around this issue in client. only clients can do - refuse to upload to ftp files with that letter in name. but this is much more braindamaged - what do you say, if your ftp client will refuse to upload files which contain character "z" in name? from other view, it's ease to fix on server side. yeah, it will broke RFC compatibility, but it will broke feature, which is not used in last 10+ years anyway AFAIK. upstream doesn't accepted that patch because it will broke RFC compatibility. unlike including patch in main source tree Gentoo users has unique feature - USE-flags. with USE-flag Gentoo users will be able to use or not to use this patch. and I think it's good idea to provide this fix for _critical_ bug as optional feature controlled by USE-flag.
I agree with Alex here. Without this patch twoftpd is not useful for Russian users. Similar fix exist for proftpd, and it was included upstream in 1.3.1, and although I failed to find link on commit I found patch applied in FreeBSD: http://www.freebsd.org/cgi/query-pr.cgi?pr=127096 Similar patches exist for other ftp servers. This issue was brought to twoftpd upstream but some upstream refuse to ignore RFC although this is really stupid! This is case where distributions should ignore upstream decision and fix this issue on their own. BTW, we are even in better situation then the other distributions since we can apply changes based on USE flags, so only those who need this patch will have fixes in... Thilo, please, reconsider decision. We can fix this bug :)
alright: what USE flag do you guys propose?
Probably no one of existing flags will go, so we'll need new flag. Maybe "noiac"?
(In reply to comment #9) > Probably no one of existing flags will go, so we'll need new flag. > Maybe "noiac"? May be breakrfc. noiac is also good. Break RFC compliance to allow control symbols in filenames (required for some (e.g. cp1251) encodings, use with caution)
1.21-r1 is now in cvs with this change. thank you very much
