This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
JavaCVS module can't handle Japanese path name and Japanese message. [1]Japanese filename/module name (a) Add/Refresh/Recursive Refresh/Status commands can't handle Japanese filename and module name correctly. These commands are executed and then the following exception occurs. Exception -> org.netbeans.lib.cvsclient.command.CommandException : Underlying exception : null How to reproduce ---------------- 1. Make a working directory with Japanese name or a working directory contained files with Japanese filename. 2. Add the working directory or the files to an appropriate repository. 3. Execute Refresh/Recursive Refresh/Status commands to the working directory or the files. (b) As it checkout a file that has been already stored as the repository file with Japanese filename, Japanese filename is garbled in a working directory. But Checkout command can succeed in the execution and the Japanese content(data) is not garbled (can be read). How to reproduce ---------------- 1. Import and commit a working directory contained files with Japanese filename by other version control system tool to an appropriate repository. 2. Make new working directory. 3. Checkout the files with Japanese filename to new working directory made at step 2. 4. Check the files in new working directory. [2]Japanese message As it runs a CVS command with Japanese message, for instance the commit command, the Japanese message's characters are garbled (can't be read) in the reository file and CVS log output window. How to reproduce ---------------- 1. Prepare a repository and its working directory contained some files. The working directory and files don't have Japanese filename. 2. Modify the files. 3. Commit the modified files with Japanese message. 4. Check the repository files and the CVS log output window. Testing Environment - Forte for Java, EE v.3.0 (Build 010404) Solaris 8 u2, ja_JP.EUC_JP Japanese developer usualy use Japanese filename and directory(module) name. Besides, other version control systems that can be implemented in IDE can correctly handle them. Need to be fixed.
1A.. are only the specified commands not working (add/refresh/status)? what about other commands? Log/update/diff/etc.? 2. Can the japanese characters be read correctly when typing the message? I suppose the cvs executable (when run from the command line works correctly here, right?) Any idea what could be wrong? Robert, Thomas?
one more question.. just to be sure. Does any action you mentioned here, work with the command-line cvs executable outside of IDE? Or is it failing as well?
Created attachment 1146 [details] Snapshot of IDE Explorer.
> 1A.. are only the specified commands not working (add/refresh/status)? > what about other commands? Log/update/diff/etc.? --> Commit and Status commands doesn't work well. The rest of the commands can't work because the target file can't add to the repository in the first place. > 2. Can the japanese characters be read correctly when typing the message? > I suppose the cvs executable (when run from the command line works correctly > here, right?) --> Yes. Japanese characters can be read when typing the message and displaying a file located in working directory in the IDE explorer. However if a file is checked out from a repository, Japanese filename can't be read in the explorer. Please see the attachment. The filename under test_cvs directory can read but the filename under work1 directory can't read. The file under work1 was checked out from the repository. > one more question.. just to be sure. > Does any action you mentioned here, work with the command-line cvs executable > outside of IDE? Or is it failing as well? --> The command line cvs does work correctly.
I don't know how to fix the problem. the cvs protocol uses both binary and text (line-based) stream at once. The cvs itself doesn't care about encoding. As described in the cvs document describing the protocol: (in chapter 5.3) "Characters outside the invariant ISO 646 character set sould be avoided in filenames ..." However that's only a part of the problem. The bigger part of the problem lies in java.io package: for binary data, Input/OutputStreams are used, for transmission of text data, the Readers/Writers are used. However The binary/text data mixes here in one stream. The protocol needs to be read line-by-line. And the binary data in bytes. I need to read exactly the right amout of text/binary data or otherwise the data is corrupted. However the Readers perform buffering (reading ahead), which is a problem. I've tried to solve the issue by overwriting the InputStreamReader class so that it dosn't buffer. I gave us, because it uses some sun.io classes which is not acceptable to use. The classes in question are byte to char converters. I'm currently not aware of a way how to get the right encoding and convert the right parts of the stream ot chars while preserving the rest in binary.
Okay, Milos plans to resolve this issue later. Therefore I mark this issue accordingly. Waiting for two versions of JDK 1.4 released in a row ...
Marking as P2 since we need this for future loclized releases. ken.frank@sun.com 03/12/2002
Frank, please note that this issue does not depend on us, therefore we can't guarantee that it will be fixed in next release of Forte. At least definetely not in Forte for Java 4.0.
*** Issue 21996 has been marked as a duplicate of this issue. ***
Target milestone was changed from not determined to TBD
Consistent use of the I18N keyword.
I've not tried localized names, but localized messages can be fixed. This issue is going to be fixed together with issue #27547.
Hopefully fixed in the main trunk. The conversion between bytes and characters is performed according to the current locale: /cvs/javacvs/libsrc/org/netbeans/lib/cvsclient/util/LoggedDataInputStream.java,v <-- LoggedDataInputStream.java new revision: 1.9; previous revision: 1.8 done Checking in org/netbeans/lib/cvsclient/util/LoggedDataOutputStream.java; /cvs/javacvs/libsrc/org/netbeans/lib/cvsclient/util/LoggedDataOutputStream.java,v <-- LoggedDataOutputStream.java new revision: 1.8; previous revision: 1.7 done RCS file: /cvs/javacvs/libsrc/org/netbeans/lib/cvsclient/util/ByteArray.java,v done Checking in org/netbeans/lib/cvsclient/util/ByteArray.java; /cvs/javacvs/libsrc/org/netbeans/lib/cvsclient/util/ByteArray.java,v <-- ByteArray.java initial revision: 1.1 done
Akiko, now I would like to ask you if you could verify this issue. Could you help us with this ? Thank you very much !
Hello Jiri, I've verified the fixing in "S1S Nevada (Build 030224)" with support of Akiko. Thank you - Hiroshi.
just a testing comment, please ignore it