Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 367021

Summary: deleted links loose target when calling DeltaBuildDetector
Product: [Eclipse Project] Platform Reporter: valentin Mising name <intellij>
Component: ResourcesAssignee: Platform-Resources-Inbox <platform-resources-inbox>
Status: RESOLVED INVALID QA Contact:
Severity: normal    
Priority: P3 CC: Szymon.Brandys
Version: 4.2   
Target Milestone: ---   
Hardware: PC   
OS: Windows 7   
Whiteboard:

Description valentin Mising name CLA 2011-12-17 15:04:59 EST
Build Identifier: M20110909-1335

DeltaBuildDetector.visit(IResourceDelta delta) is notified every time a project resource is changed (added/deleted/modified). When a link is added or linked resource is modified then everything is ok, delta.resource is has proper local and target location. They are computed by getFullName() and getLocation() respectively. The problem is the delete delta. 

When link is deleted, delta.getResource().getLocation() returns some garbage.

Reproducible: Always

Steps to Reproduce:
1.create a link to a file
2.set breakpoint in the DeltaBuildDetector.visit(IResourceDelta delta)
3.delete the link

Observe that the delta.getResource().getLocation() is different from the linked file.
Comment 1 valentin Mising name CLA 2011-12-18 08:50:46 EST
Excuse me. I mean that DeltaBuildDetector implements IResourceDeltaVisitor inside IncrementalProjectBuilder and suppose that you know how to add it.
Comment 2 valentin Mising name CLA 2011-12-18 14:06:00 EST
Here is a reproducing code

	static {
		   IResourceChangeListener listener = new IResourceChangeListener() {
			      public void resourceChanged(IResourceChangeEvent event) {
				      //System.err.println(String.format("Something changed! build kind = %s, res = %s, src = %s, type = %s", event.getBuildKind(), event.getResource(), event.getSource(), event.getType()));
			    	  //iterate(event.getDelta().getResource(), " ", event.getDelta().getKind());
			    	    try {
			    	        event.getDelta().accept(new IResourceDeltaVisitor() {
			    	            public boolean visit(IResourceDelta delta) throws CoreException {
			    	            	IResource res = delta.getResource();
			    	                if (delta.getResource().getType() == IResource.FILE) {
								        System.err.println(String.format("fullpath = %s, target = %s, delta kind = %s", res.getFullPath(), res.getLocation(), delta.getKind()));
			    	                }
			    	                return true;
			    	            }
			    	        });
			    	    } catch (CoreException e) {
			    	        // handle error
			    	    }
			      }
			   };
			   ResourcesPlugin.getWorkspace().addResourceChangeListener(listener);

	}

Linking C:\1 and deleting it afterwards produces the following output:

fullpath = /r/1, target = C:/1, delta kind = 1 (ADD)
fullpath = /r/1, target = C:/Users/valentin/runtime-EclipseApplication/r/1, delta kind = 2 (DELETE)

You see how file location has changed from C:\1 to PROJECT_LOC\1
Comment 3 Szymon Brandys CLA 2011-12-19 05:28:04 EST
This is intended behavior. At the time when the DELETE event is thrown, the resource does not exist already. And according to the #getLocation javadoc "If this resource is a file or folder under a project that exists, or a linked resource under a closed project, this method returns a (non-null) path computed from the location of the project's local content area and the project-relative path of the file or folder. This is true regardless of whether the file or folders exists, or whether the project is open or closed."