Bug 197157 - Old compilation unit contents retrieved even after file is deleted
Summary: Old compilation unit contents retrieved even after file is deleted
Status: VERIFIED WORKSFORME
Alias: None
Product: JDT
Classification: Eclipse Project
Component: Core (show other bugs)
Version: 3.3   Edit
Hardware: PC Windows XP
: P3 major (vote)
Target Milestone: 3.4 M2   Edit
Assignee: Jerome Lanneluc CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2007-07-19 11:23 EDT by Tom Mutdosch CLA
Modified: 2007-09-18 06:48 EDT (History)
1 user (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Tom Mutdosch CLA 2007-07-19 11:23:16 EDT
I create a compilation unit via some codegeneration in my plugin and save it out.  Then from Project Explorer, I delete that java file.  Then if in my code I do:
ICompilationUnit cu = JavaCore.createCompilationUnitFrom(myDeletedFile);
IType currentType = cu.findPrimaryType();

I get back the contents of the deleted file as if they had not been deleted.  It seems that the contents are being cached somehow and not flushed when the resource is deleted.

I also see similar behavior where the Project Explorer will get out of sync with files that have been created programatically, where the explorer will show a Java file that has been deleted, and when you click on that file it opens up in the editor with a message saying "this file has been deleted".
Comment 1 Olivier Thomann CLA 2007-07-19 11:35:07 EDT
Are you deleting the files from outside of the Eclipse workspace ?
Comment 2 Tom Mutdosch CLA 2007-07-19 13:12:48 EDT
No, the file is not deleted outside of the workspace.  I am always deleting from the Project Explorer.  

FYI, not sure if it matters, but I am creating the java classes programatically via:
 ICompilationUnit cu = pack.createCompilationUnit(clName + ".java",
		                 myContent, true, monitor);

Comment 3 Jerome Lanneluc CLA 2007-08-10 10:58:24 EDT
Sorry Tom I cannot reproduce. I added DeleteTests.testDeleteCompilationUnit5() that hopefully reflects the problem you're describing, and this test passed.

public void testDeleteCompilationUnit5() throws CoreException {
	try {
		IPackageFragment pkg = getPackage("/P");
		pkg.createCompilationUnit(
			"X.java", 
			"public class X {\n" +
			"}",
			true,
			null
		);
		// force opening
		getCompilationUnit("P/X.java").open(null);
		
		IFile file = getFile("P/X.java");
		file.delete(true, null);

		ICompilationUnit cu = JavaCore.createCompilationUnitFrom(file);
		IType type = cu.findPrimaryType();
		assertNull("Should not find primary type", type);
	} finally {
		deleteFile("P/X.java");
	}
}
Comment 4 Jerome Lanneluc CLA 2007-08-22 11:40:22 EDT
Please reopen if you have more details.
Comment 5 Tom Mutdosch CLA 2007-08-22 13:19:05 EDT
I do still see this...  I'm wondering if in my case maybe someone is holding onto a model or something like the WorkingCopy document model and not releasing it.  Would that cause this behavior?  So it's likely not an eclipse issue, but probably another client.  Just curious if that could be the culprit.
Comment 6 Jerome Lanneluc CLA 2007-08-23 09:33:09 EDT
You're right. If someone made the cu a working copy (using ICompilationUnit#becomeWorkingCopy()) and the working copy was not discarded (using ICompilationUnit#discardWorkingCopy()) before you deleted the file, then the content of the working copy will be used when calling findPrimaryType().
Comment 7 Tom Mutdosch CLA 2007-08-23 09:37:59 EDT
Okay, thanks.  That does appear to be what is happening.  I will follow up with the offending participant.  Appreciate your taking the time to help. 
Comment 8 Frederic Fusier CLA 2007-09-18 06:48:23 EDT
Verified for 3.4 M2 using build I20070917-0010.