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

Bug 24532

Summary:	[Navigator] Copying file to .classpath leads to hang
Product:	[Eclipse Project] JDT	Reporter:	Grant Gayed <grant_gayed>
Component:	Debug	Assignee:	JDT-Core-Inbox <jdt-core-inbox>
Status:	RESOLVED DUPLICATE	QA Contact:
Severity:	normal
Priority:	P3
Version:	2.0
Target Milestone:	---
Hardware:	PC
OS:	All
Whiteboard:

Description Grant Gayed

2002-10-08 14:46:22 EDT

1008 integration build, happens on at least win2000 and linux-motif

- create CVS connection to dev.eclipse.org
- retrieve project org.eclipse.swt from HEAD
- in Resource Navigator select contained file .classpath_win32 (assuming that 
you're working on windows), right-click -> Copy
- select the org.eclipse.swt project, right-click -> Paste
- a Name Conflict dialog pops up, sets its value to ".classpath" (no quotes), OK
- a progress dialog is popped up to show work starting, but after ~ a second 
another progress dialog is popped up right on top of the first one, and it 
seems like a lock occurs between them

Note that these are the steps that swt goes through whenever retrieving 
contents from the repository, so we can't upgrade until this is fixed.

Comment 1 Grant Gayed

2002-10-09 09:48:03 EDT

This problem is actually much more widespread than the original test steps 
indicate.  Here's a much more common scenario:

- new workspace
- File -> Import...
- External Plugins and Fragments, Next
- Next
- Select All, Finish

It imports the projects quickly, but then goes to compile something and hangs 
again.  I'd say that Eclipse is unusable by all, not just swt, until this is 
fixed.

Comment 2 Knut Radloff

2002-10-09 10:35:48 EDT

Eclipse also hangs if I turn auto build off, rename the classpath file, turn 
autobuild back on. Seems to be build related.
Moving to JDT Core.

Comment 3 Knut Radloff

2002-10-09 12:36:16 EDT

The rename classpath, turn autobuild on scenario I describe above is resulting 
in the same stacks for the two ModalContext threads that are shown in the 
second attachment of bug 24579.
The main thread stack is different because the build is triggered by closing 
the preference dialog instead of a repository check out.
Marking this as duplicate sine bug 24579 has more information.

*** This bug has been marked as a duplicate of 24579 ***