Bug 35991 - Getting resource exception on Team replace from repository
Summary: Getting resource exception on Team replace from repository
Status: RESOLVED WORKSFORME
Alias: None
Product: Platform
Classification: Eclipse Project
Component: Resources (show other bugs)
Version: 2.1   Edit
Hardware: PC Windows 2000
: P3 normal (vote)
Target Milestone: ---   Edit
Assignee: John Arthorne CLA
QA Contact:
URL:
Whiteboard:
Keywords: investigate
Depends on:
Blocks:
 
Reported: 2003-04-02 13:31 EST by Richard Kulp CLA
Modified: 2005-01-13 11:45 EST (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 Richard Kulp CLA 2003-04-02 13:31:12 EST
I'm not sure what is causing this or if I did something wrong. But I have a
project connected to a CVS repository. I'm doing a replace with latest and
during the build that results I get the message:

A build error occurred after the CVS operation completed.

Reason:
Resource
/com.ibm.etools.beaninfo/beaninfo/com/ibm/etools/beaninfo/export does not exist.

This folder had been deleted in the past and shouldn't exist now. Though of
course CVS still has a record that it existed, but the current branch isn't
using it.

The following trace occurs in the .log file:

!MESSAGE Problems occurred when invoking code from plug-in:
"org.eclipse.core.resources".
!STACK 1
org.eclipse.core.internal.resources.ResourceException: Resource
/com.ibm.etools.beaninfo/beaninfo/com/ibm/etools/beaninfo/export does not exist.
	at org.eclipse.core.internal.resources.Resource.checkExists(Resource.java:302)
	at org.eclipse.core.internal.resources.Resource.checkAccessible(Resource.java:174)
	at
org.eclipse.core.internal.resources.Resource.getPersistentProperty(Resource.java:878)
	at com.ibm.rtp.tools.rose.Builder$1.visit(Builder.java:118)
	at org.eclipse.core.internal.events.ResourceDelta.accept(ResourceDelta.java:71)
	at org.eclipse.core.internal.events.ResourceDelta.accept(ResourceDelta.java:79)
	at org.eclipse.core.internal.events.ResourceDelta.accept(ResourceDelta.java:79)
	at org.eclipse.core.internal.events.ResourceDelta.accept(ResourceDelta.java:79)
	at org.eclipse.core.internal.events.ResourceDelta.accept(ResourceDelta.java:79)
	at org.eclipse.core.internal.events.ResourceDelta.accept(ResourceDelta.java:79)
	at org.eclipse.core.internal.events.ResourceDelta.accept(ResourceDelta.java:79)
	at org.eclipse.core.internal.events.ResourceDelta.accept(ResourceDelta.java:52)
	at com.ibm.rtp.tools.rose.Builder.incrementalBuild(Builder.java:79)
	at com.ibm.rtp.tools.rose.Builder.build(Builder.java:61)
	at org.eclipse.core.internal.events.BuildManager$2.run(BuildManager.java:427)
	at
org.eclipse.core.internal.runtime.InternalPlatform.run(InternalPlatform.java:889)
	at org.eclipse.core.runtime.Platform.run(Platform.java:413)
	at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:125)
	at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:181)
	at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:191)
	at org.eclipse.core.internal.events.BuildManager$1.run(BuildManager.java:151)
	at
org.eclipse.core.internal.runtime.InternalPlatform.run(InternalPlatform.java:889)
	at org.eclipse.core.runtime.Platform.run(Platform.java:413)
	at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:165)
	at
org.eclipse.core.internal.events.BuildManager.basicBuildLoop(BuildManager.java:243)
	at org.eclipse.core.internal.events.BuildManager.build(BuildManager.java:212)
	at org.eclipse.core.internal.resources.Workspace.endOperation(Workspace.java:884)
	at org.eclipse.core.internal.resources.Workspace.run(Workspace.java:1600)
	at
org.eclipse.ui.actions.WorkspaceModifyOperation.run(WorkspaceModifyOperation.java:85)
	at
org.eclipse.team.internal.ccvs.ui.repo.RepositoryManager.run(RepositoryManager.java:796)
	at org.eclipse.team.internal.ccvs.ui.actions.CVSAction$1.run(CVSAction.java:242)
	at
org.eclipse.jface.operation.ModalContext$ModalContextThread.run(ModalContext.java:101)
!ENTRY org.eclipse.core.resources 4 368 Apr 02, 2003 11:34:46.662
!MESSAGE Resource
/com.ibm.etools.beaninfo/beaninfo/com/ibm/etools/beaninfo/export does not exist.
!SUBENTRY 1 org.eclipse.core.resources 4 368 Apr 02, 2003 11:34:46.662
!MESSAGE Resource
/com.ibm.etools.beaninfo/beaninfo/com/ibm/etools/beaninfo/export does not exist.
!ENTRY org.eclipse.core.resources 4 368 Apr 02, 2003 11:36:04.904
!MESSAGE Resource
/com.ibm.etools.beaninfo/beaninfo/com/ibm/etools/beaninfo/export does not exist.


I also did a little debugging. The ResourceDelta in question in the above trace
has the following status field value:  decimal 262148  (It looks like this means
"Phantom_added, Replaced, Markers, Moved_to, Content", though there are two bits
set that I can't figure out what they mean).

When I do a normal "Checkout as Project", or Synchronize, or Rebuild project
there are no problems. Only occurs on Replace with latest from Repository.

Thanks, Rich Kulp
Comment 1 John Arthorne CLA 2003-04-02 14:00:01 EST
262148 = 2^18 + 2^2, so only two bits are set: CHANGED, and REPLACED.  Can you
confirm that this is the value of the delta?  To be sure, do the following with
the delta:

((ResourceDelta)delta).toDebugString()

and let us know what this prints out.  Better yet, you can call:

((ResourceDelta)delta).toDeepDebugString() on the root of the builder's delta to
find out what the entire delta tree looks like.

The stack trace shows that the builder is trying to access a persistent property
for a resource that doesn't exist locally.  My first guess is that the builder
(com.ibm.rtp.tools.rose.Builder) is misinterpreting the delta, and incorrectly
believing that the resource still exists.  
Comment 2 Richard Kulp CLA 2003-04-02 14:29:25 EST
Thanks for the info. I didn't realize what builder was actually causing the
problem until you just pointed it out in your reply. It is a local builder
someone here had written.

The debug string is:
/com.ibm.etools.beaninfo/beaninfo/com/ibm/etools/beaninfo/export[*]: {REPLACED}

However, I have a question of why does it indicate it has replaced, but yet the
folder doesn't really exist? Should this be a valid resource delta state? Should
there be something else the builder should be checking on for something like
this? This folder was in CVS and has been deleted from the branch,so it
shouldn't be in the project.

Thanks again,
Rich
Comment 3 Richard Kulp CLA 2003-04-03 10:11:08 EST
Since it turns out to be a local bug and not an Eclipse bug, I'm closing this
report as invalid. 

I don't understand why the folder is showing up in the resource delta since it
doesn't exist, but we'll change the builder to do an exists test first before
accessing the persistent store.

Thanks for the help,
Rich
Comment 4 John Arthorne CLA 2003-04-03 10:52:46 EST
Even when you've deleted a folder locally, CVS may still keep them around as
"phantom" resources because they have important information attached to them.
You shouldn't be seeing phantoms in the delta unless you specifically request
them.  When the builder calls IResourceDelta.accept, the "int" parameter is used
to specify whether phantoms and team private resources should be included.  If
you have access to the builder code could you tell me what the call to
IResourceDelta.accept looks like?

I'm going to re-open this bug, because I'm not convinced our behaviour is
correct in the case of changed phantoms.  We probably thought this was not
possible, but in the case of a replaced resource, it is possible.  
Comment 5 Richard Kulp CLA 2003-04-03 11:08:15 EST
It uses a straight delta.accept(IResourceDeltaVistor); in the incremental build.
In the fullbuild it uses project.accept(IResourceVisitor);  No other arguments
to both the accepts, just the visitor.
Comment 6 John Arthorne CLA 2003-04-04 11:04:45 EST
We need to update our IResourceDelta API and implementation to describe what
happens in the case of changed phantoms.  We probably thought at design time
that phantom changes weren't possible, but it turns out to be possible: delete,
recreate, then convert to phantom all in one operation will yield a CHANGED +
REPLACED  delta.  These deltas should be excluded from visitors unless
specifically requested.

Richard, the workaround for your builder until we fix this is to do an exists()
check on the resource in the visitor, and ignore non-existent resources. 

The phantom menace strikes again ;) 
Comment 7 Richard Kulp CLA 2003-04-04 11:15:18 EST
Thanks, I just tried it and that workaround works well.
Comment 8 John Arthorne CLA 2005-01-13 11:45:33 EST
I tried various test scenarios to make this happen, but couldn't reproduce.  The
ResourceDelta.accept() method checks the phantom bit on the new resource info,
so I don't see any way how a phantom could leak through to a normal visitor. 
Perhaps the code has changed since this bug was reported.  In any case, I have
released my automated test cases that verify that this is working
(regression.IResourceTest#testBug35991).  If it happens again, I'll reopen.