Bug 194293 - [Local][Archives] Saving file second time in an Archive Errors
Summary: [Local][Archives] Saving file second time in an Archive Errors
Status: CLOSED FIXED
Alias: None
Product: Target Management
Classification: Tools
Component: RSE (show other bugs)
Version: 2.0   Edit
Hardware: PC Windows XP
: P3 normal (vote)
Target Milestone: 2.0.1   Edit
Assignee: Xuan Chen CLA
QA Contact: Martin Oberhuber CLA
URL:
Whiteboard:
Keywords: contributed
: 187384 (view as bug list)
Depends on:
Blocks:
 
Reported: 2007-06-25 15:53 EDT by Kevin Doyle CLA
Modified: 2011-05-25 09:36 EDT (History)
3 users (show)

See Also:


Attachments
Fix for bug 194293 (6.49 KB, patch)
2007-07-08 21:58 EDT, Xuan Chen CLA
no flags Details | Diff
Updated according to DaveM's comment. (6.70 KB, patch)
2007-07-12 12:20 EDT, Xuan Chen CLA
no flags Details | Diff
change the method as private methods for Tar and Zip handlers (7.22 KB, patch)
2007-07-12 13:54 EDT, Xuan Chen CLA
mober.at+eclipse: iplog+
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Kevin Doyle CLA 2007-06-25 15:53:43 EDT
After saving a file that is located in an archive for a second time I get the following error dialog message:

Operation failed. File system input or output error
Details: Message reported from file system: java.lang.NullPointerException

This only happens on Local.  DStore Archive files work fine.

Log file:
!ENTRY org.eclipse.rse.ui 4 0 2007-06-25 15:51:22.142
!MESSAGE RSEF1002E: SUB#0:java.lang.NullPointerException

Steps to Reproduce:
1. Create a new file called dummy.zip on Local.
2. Inside dummy.zip create a new file called test.txt
3. Open test.txt
4. Add some text and save the file.
5. Add some more text and save the file.
--> Error Dialog Appears.

-----------Enter bugs above this line-----------
TM 2.0RC4 Testing
installation : eclipse-SDK-3.3RC4
RSE install  : RSE 2.0 RC4
java.runtime : Sun 1.5.0_11-b03
os.name:     : Windows XP, Service Pack 2
------------------------------------------------
Comment 1 Xuan Chen CLA 2007-06-26 00:10:32 EDT
I found that it only happens to the files which are the immediate children of the zip file.  e.g., myzip.zip/#virtual/aa.txt.  If a file exists inside a virtual folder, it works fine.


It seems the problem is in the SystemZipHandler#add() method:

public boolean add(File file, String virtualPath, String name, String sourceEncoding, String targetEncoding, boolean isText) 
	{
		if (!_exists) return false;
		virtualPath = ArchiveHandlerManager.cleanUpVirtualPath(virtualPath);
		if (!file.isDirectory())
		{
			if (exists(virtualPath + "/" + name)) //$NON-NLS-1$
			{
				// wrong method
				return replace(virtualPath + "/" + name, file, name); //$NON-NLS-1$
			}
			else
			{
   .
   .
   .


As you can see, if a virtual path is "", the fullVirtualName of this virtual file passed to replace() method will be something like "/filename.txt", instead of "filename.txt". 

So we need to handle this special case separately.

The change will be something like this:

	public boolean add(File file, String virtualPath, String name, String sourceEncoding, String targetEncoding, boolean isText) 
	{
		if (!_exists) return false;
		virtualPath = ArchiveHandlerManager.cleanUpVirtualPath(virtualPath);
		
		if (!file.isDirectory())
		{
			String fullVirtualName = null;
			if (virtualPath == null || virtualPath.length() == 0)
			{
				fullVirtualName = name;
			}
			else
			{
				fullVirtualName = virtualPath + "/" + name;  //$NON-NLS-1$
			}
			if (exists(fullVirtualName)) 
			{
				return replace(fullVirtualName, file, name);
			}
			else
			{
          .
          .
          .


Comment 2 Martin Oberhuber CLA 2007-06-28 09:35:41 EDT
Xuan can you come up with a patch?
Comment 3 Xuan Chen CLA 2007-07-08 21:58:56 EDT
Created attachment 73285 [details]
Fix for bug 194293

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.
Comment 4 Xuan Chen CLA 2007-07-09 12:01:45 EDT
*** Bug 187384 has been marked as a duplicate of this bug. ***
Comment 5 Xuan Chen CLA 2007-07-11 18:21:43 EDT
Please take a look at this patch to see if it is ok.

I probably need to change these source for the other archive problem I am going to investigate.  Thanks.
Comment 6 David McKnight CLA 2007-07-12 10:25:54 EDT
Xuan, it looks like there is some code that is duplicated a few times in the patch.  For example:

if (virtualPath == null || virtualPath.length() == 0)
{
  fullVirtualName = names[i];
}
else
{
 fullVirtualName = virtualPath + "/" + names[i];  //$NON-NLS-1$
}

I would be cleaner if you could create a couple methods to do these things.
Comment 7 Xuan Chen CLA 2007-07-12 12:20:01 EDT
Created attachment 73679 [details]
Updated according to DaveM's comment.

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.
Comment 8 Xuan Chen CLA 2007-07-12 13:45:00 EDT
Since the change is to add a non-private method in ArchiveHandlerManager, which is not an internal class, it is an API change (thanks Kevin for reminding me).  
I will create one private method each in both SystemZipHandler and SystemTarHandler for now.  And will move it to ArchiveHandlerManager later.
I will open another bug to track it.
Comment 9 Xuan Chen CLA 2007-07-12 13:54:45 EDT
Created attachment 73685 [details]
change the method as private methods for Tar and Zip handlers

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.
Comment 10 David McKnight CLA 2007-07-12 16:56:56 EDT
I've committed the patch.
Comment 11 Kevin Doyle CLA 2007-07-15 16:08:07 EDT
Verified with I20070713-0605.