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

Bug 320533

Summary:	Replacing text in a set of files should only modify each physical resource once
Product:	[Eclipse Project] Platform	Reporter:	Jonathan Locke <jonathan.locke>
Component:	Search	Assignee:	Dani Megert <daniel_megert>
Status:	VERIFIED FIXED	QA Contact:
Severity:	critical
Priority:	P2	CC:	daniel_megert, jasonsj, markus.kell.r, r.berg, raksha.vasisht, remy.suen, yevshif
Version:	3.6
Target Milestone:	3.7 M7
Hardware:	All
OS:	All
Whiteboard:

Description Jonathan Locke

2010-07-21 12:54:01 EDT

Build Identifier: 20100617-1415

I've triple checked this to make sure it wasn't a problem with my search/replace operation because it seemed quite unbelievable to me, but replacing "new Frequency" with "Frequency.every" in hundreds of files resulted in mangled replacement text in many of the replacement locations. I get Frequency.everyry, Frequency.everyvery, and others. And trying to file replace the mistakes to correct them just made the problem worse so I had to manually fix each file.

Reproducible: Always

Steps to Reproduce:
1. Take a source tree
2. Replace text
3. Notice horrible mistakes :)

If this doesn't repro, happy to provide more details...

Comment 1 Dani Megert

2010-07-22 04:27:34 EDT

I can only assume what happened given the sparse information: I suspect that in your workspace several Eclipse resources are pointing to identical physical files or folders. While this is a valid setup for more complicated projects, you have to be aware that Eclipse is resource based and hence if you do a search it will find the match for all Eclipse resources e.g. if you search for "test" in project A:
A
 f1 -> c:\foo.txt (with "test" in it)
 f2 -> c:\foo.txt (with "test" in it)
==> will find two matches: /A/f1 and /A/f2.

This is the intended behavior which we won't change but obviously we should not corrupt any files. When replacing text in a bunch of files we should be smarter and remember which physical resource we already modified.


Is that your setup?

Comment 2 Dani Megert

2010-07-22 04:28:26 EDT

*** Bug 303715 has been marked as a duplicate of this bug. ***

Comment 3 Jonathan Locke

2010-07-22 10:06:06 EDT

yes, but i'm afraid that is a fairly typical setup these days.  on any decent sized project, you have nested maven projects and you have to have the root in your workspace too (to export patches from and commit from, mostly).  i've been wanting for a long time to exclude the root project from all search and replace operations (i always get duplicates whenever i search my workspace).  or even better: couldn't search determine the set of unique physical resources to operate on so it doesn't do things twice?  it's definitely what i would expect as a user.

Comment 4 Dani Megert

2010-07-22 13:00:27 EDT

>better: couldn't search determine the set of unique physical resources to
>operate on so it doesn't do things twice?  
No, that's not an option. You could use working sets for search.

Comment 5 Dani Megert

2011-03-18 10:24:15 EDT

Fixed in HEAD (ReplaceRefactoring.java, rev. 1.8).
Available in builds >= N20110318-2000.

Comment 6 Dani Megert

2011-04-15 06:24:59 EDT

The fix caused a regression, see bug .

The correct fix is in ReplaceRefactoring.java, rev. 1.9.
Available in builds >= N20110415-2000.

Comment 7 Raksha Vasisht

2011-04-26 07:11:30 EDT

Verified for 3.7M7 with I20110425-1800.

Comment 8 Markus Keller

2011-05-13 15:02:38 EDT

*** Bug 345754 has been marked as a duplicate of this bug. ***

Comment 9 Markus Keller

2011-05-13 15:04:39 EDT

The regression was bug 342932. And in 3.7 RC1, bug 343821 fixed a UI problem in the Search view.