Community
Participate
Working Groups
+++ This bug was initially created as a clone of Bug #179937 +++ The dstore server should report the System.getProperty("file.encoding") that it uses to the client. This System property is used for translating remote system file and path names into Unicode, which is then shipped over the wire. If this setting is incorrect for any reason (e.g. because multiple different encodings are used in different branches of the file system -- see bug 179937), the client needs to decode the Unicode into the original byte stream before it can re-code properly. Knowing the original encoding is vital for this to work. Therefore, the dstore server has to report its file.encoding property to the client. Ideally, this should work without any incompatible API or protocol changes. BIDI3.3:HCG_ UTF-8 not supported for path and file names Scenario to recreate: 1. Connect to Linux machine using terminal emulator working in UTF-8 encoding. (You can use PUTTY with translation set to UTF-8. Optionally, run shell application (gnome-terminal or konsole) in UTF-8 locale.) 2. Create file with Hebrew characters in its name 3. Create RSE connection to the Linux machine using either SSH or DStore 4. Look at the file name into Remote Systems view of RSE. Result: Hebrew characters look like wrong symbols. Please notice, file names created with Hebrew ASCII encoding look fine. The problem appears with both UTF-8 or ASCII Hebrew encoding of a container (Eclipse). There is no option to customize encoding for connection.
Dave - you are expert on dstore, can you do this quickly?
I'm not sure I understand this one. Dstore does call System.getProperty("file.encoding") on the host in response to the C_SYSTEM_ENCODING query. On the client this query is done via the DStoreFileService.getEncoding(IProgressMonitor) call. I followed the steps to recreate this (I used Arabic characters in my case - although I would think it should reproduce the same thing as Hebrew characters). I got different results in the Remote Systems view depending on whether I used SSH or DStore. For DStore, the name appears correctly, while for SSH it doesn't. I'll attach what I see for each next.
Created attachment 66135 [details] image of bidi file name for dstore and ssh under the zzz filter, is a bidi filename. For dstore this displays fine, while I don't see it correctly for SSH.
(In reply to comment #2) > Dstore does call System.getProperty("file.encoding") on the host in response > to the C_SYSTEM_ENCODING query. That's all I wanted -- be able to query the remote what encoding it uses. If this is possible already now, feel free to close as WORKSFORME. It's true that SSH doesn't support this (yet) and most proably won't give full encoding support for 2.0.
This is already there.
[target cleanup] 2.0 M7 was the original target milestone for this bug
