FTP frontend should support Unicode filenames encoded as UTF-8 #682
Labels
No Label
0.2.0
0.3.0
0.4.0
0.5.0
0.5.1
0.6.0
0.6.1
0.7.0
0.8.0
0.9.0
1.0.0
1.1.0
1.10.0
1.10.1
1.10.2
1.10a2
1.11.0
1.12.0
1.12.1
1.13.0
1.14.0
1.15.0
1.15.1
1.2.0
1.3.0
1.4.1
1.5.0
1.6.0
1.6.1
1.7.0
1.7.1
1.7β
1.8.0
1.8.1
1.8.2
1.8.3
1.8β
1.9.0
1.9.0-s3branch
1.9.0a1
1.9.0a2
1.9.0b1
1.9.1
1.9.2
1.9.2a1
LeastAuthority.com automation
blocker
cannot reproduce
cloud-branch
code
code-dirnodes
code-encoding
code-frontend
code-frontend-cli
code-frontend-ftp-sftp
code-frontend-magic-folder
code-frontend-web
code-mutable
code-network
code-nodeadmin
code-peerselection
code-storage
contrib
critical
defect
dev-infrastructure
documentation
duplicate
enhancement
fixed
invalid
major
minor
n/a
normal
operational
packaging
somebody else's problem
supercritical
task
trivial
unknown
was already fixed
website
wontfix
worksforme
No Milestone
No Assignees
3 Participants
Notifications
Due Date
No due date set.
Reference: tahoe-lafs/trac-2024-07-25#682
Loading…
Reference in New Issue
No description provided.
Delete Branch "%!s(<nil>)"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
using ncftp on a put of a file with an é accent I get the following message :
[action not taken: internal server error]Requested
in the logs server side :
This is definitely the same sort of encoding issues as in #534. I'll try to have a look at it.
reformatted description slightly
See RFC 2640 for FTP internationalization.
Replying to davidsarah:
Summary:
UTF8
in the response to aFEAT
request;Admirably simple :-)
(See also #1076 about normalization, but that will probably be done in the dirnode interface rather than in frontends.)
Hmm, judging by the exception message ("'ascii' codec can't decode byte 0xe0"), ncftp was trying to use ISO-Latin-1 rather than UTF-8. But at least it would be possible for clients to do the right thing, so I still think we should implement RFC 2640.
Actually 'é' is 0xE9 in ISO-Latin-1, so I don't know what encoding this was (but not UTF-8).
FTP frontend refuses accentsto FTP frontend should support Unicode filenamesWith the new improved pyutil-1.7.9 you get this handy-dandy script called "try_decoding":
Oh hey there are no encodings known to Python 2.6.1 which would decode 0xe0 to é!
Here are all the things that all the encodings would decode 0xe0 to:
#1089 discusses the use of non-UTF-8 encodings by FTP and SFTP clients.
Replying to [davidsarah]comment:9:
Twisted's FTP implementation does not currently implement FEAT. However it is implemented in such a way that it's relatively easy to monkey-patch it to do so, and no more ugly than monkey-patching always is. Something like (untested):
I opened http://twistedmatrix.com/trac/ticket/4515 (support the FTP FEAT request).
FTP frontend should support Unicode filenamesto FTP frontend should support Unicode filenames encoded as UTF-8Twisted #4515 has been closed.
Unfortunately the fix for that ticket isn't sufficient, because
adiroiban wrote in (@@http://twistedmatrix.com/trac/ticket/4515#comment:70704@@):
With this change, it is possible to declare support for UTF-8 by monkeypatching
twisted.protocols.ftp.FTP.FEATURES
, but that depends on an implementation detail, which is what we were trying to avoid. (Granted, it's a slightly less ugly monkeypatch.)I don't know why adiroiban ignored me when I pointed out that the goal of that ticket could be achieved in a simpler way that would have been sufficient. Maybe I should have argued the case more strenuously.
Sigh, and it doesn't have a conformant implementation of OPTS:
http://tools.ietf.org/html/draft-ietf-ftpext-utf-8-option-00 says: