Community
Participate
Working Groups
Zipped file contents not correct when opened from RSE. To reproduce. 1. Create a text file with just one word. 2. In you local connection, Create a zip file that contains the new text file. 3. Expand the zip file, and open the text file thats in the zip. The text file has extra unrecognized characters added to the end of the file. Also when I open the text file using System Editor (notepad), from RSE, there are white spaces at the end of the file. However, when I open the file from WinZip, the file does not have the spaces at the end. Another problem, 1. Drag and drop a text file (with about 500 words in it) into a zip file. (i.e. you can probably use notice.html in eclipse 3.3 zipped driver) 2. Open the zipped text file in RSE. 3. Compare it to the original file. Now, the zipped text file contains extra stuff at the end of the file. It looks like random text from the original text have been copied to the end of the file. However, when I open the text file from Winzip, the contents seems to have been copied over correctly. -----------Enter bugs above this line----------- RSE 2.0M4 Testing installation : eclipse-platform-3.3M6 (I20070323-1616) RSE install : TM 2.0M6 java.runtime : Sun 1.4.2_11-b06 os.name: : Windows XP 5.1, Service Pack 2 ------------------------------------------------ systemtype : Windows-Local connection ------------------------------------------------
Xuan can you look at this?
The content of the file itself is correct. But when it is written to editor, we add extra character into it. The problem is in SystemZipHandler#extractVirtualFile(): byte[] buf = new byte[1024]; int numRead = reader.read(buf); while (numRead > 0) { if (isText) { String bufString = new String(buf, sourceEncoding); ^^^^^^^^^^^^^^^^^^^^^^^^^^^ byte[] convertedBuf = bufString.getBytes(); int newSize = convertedBuf.length; writer.write(convertedBuf, 0, newSize); } else { writer.write(buf, 0, numRead); } So, in the case of handling text file, we don't make use of numRead. The bufString will have the length of 1024 in this case. We should use: String bufString = new String(buf, 0, numRead, sourceEncoding); instead. I will provide the patch after bug 194293 has been committed.
Tar file does not have this problem.
Created attachment 73715 [details] Fix for bug 181784 Legal Message: I, Xuan Chen, declare that I developed attached code from scratch, without referencing any 3rd party materials except material licensed under the EPL. I am authorized by my employer, IBM Canada Ltd. to make this contribution under the EPL.
I committed the patch to cvs.
Since the contribution was made before Xuan became committer, it's a good question whether this needs to be logged in our IP Log (tm-log.csv in the www-tm-dev project). I filed an IPBug for this on http://dev.eclipse.org/committers/ in order to ask the EMO Legal team -- feel free to CC if you are interested. https://dev.eclipse.org/ipzilla/show_bug.cgi?id=1632 Until this is resolved, I'm setting keyword "contributed" and target milestone 2.0.1 -- Xuan please do add it to the tm-log.csv file (as an exercise :-)
I updated tm-log.csv. Please check to see if it is correct. It seems I just need to update it directly in my workspace. Didn't need to commit the change.
Verified this problem is fixed in 2.0.1 RC1 driver.
