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

Bug 32437

Summary:	Items sometimes not marked dirty when text saved
Product:	[Eclipse Project] Platform	Reporter:	Kevin McGuire <Kevin_McGuire>
Component:	Team	Assignee:	Jean-Michel Lemieux <jean-michel_lemieux>
Status:	RESOLVED FIXED	QA Contact:
Severity:	normal
Priority:	P3
Version:	2.1
Target Milestone:	2.1 RC2
Hardware:	PC
OS:	Windows XP
Whiteboard:

Description Kevin McGuire

2003-02-20 20:24:06 EST

I am not sure what the conditions are for this to fail but the following steps 
should work:

1. check out org.eclipse.resources (with no other prereq projects)
2. in either the resources or JDT packages views, expand it down to a class
3. type some garbage into the class and save

The class or its parents aren't marked dirty.  If you save again they will be.
Note the project has build errors.

Comment 1 Jean-Michel Lemieux

2003-02-20 21:31:28 EST

Fixed released to HEAD.
Problem was that we were trying to be too smart and in some cases it didn't work
out for us. This case involved the session cache remembering when files were
updated and thus must be clean. However this mechanism only worked if the
updated bit was cleared at some point in the timeframe of the update operation
so that when the resource is really modified it can get marked as modified.

Fix was made to EclipseFile::handleModification(). The check for the update flag
was removed.

Comment 2 Michael Valenta

2003-02-25 13:10:40 EST

It looks to me like the checking for the session property was removed but the 
setting was left in. The session property is cleared when the modified state of 
a file changes but will remain until shutdown for files that do not get 
modified.

Comment 3 Michael Valenta

2003-02-25 13:35:43 EST

In light of bug 28416, I wonder if we should try to correct the actual error 
instead of removing the mechanism. The problem is that the mechanism was first 
created for update_existing and it worked (at least no bugs were reported). 
Subsequent to that, created files were also marked but the delta listener was 
not modified to also clear the bit for created files. Given that the original 
mechanism seemed to work, I think it would be relatively low risk to add the 
check back. If others do not feel this way, the other option for bug 28416 is 
to traverse the whole tree after a checkout and mark all the managed resources 
as clean.

Comment 4 Michael Valenta

2003-02-25 14:47:50 EST

The proper behavior could be ensured if, instead of just using a bit, we cache 
the Core modification timestamp in the update handler and check that the cached 
timestamp equals the actual timestamp in the delta listener. This way, any 
modification of the file that happened subsequent to the marking but before the 
delta listener checked would be detected (and any missed deltas would be 
properly handled on the next delta).

Comment 5 Jean-Michel Lemieux

2003-03-03 14:15:38 EST

FileModificationManager is now used to cache the timestamp of files made clean
via a CVS commands. This optimizes the dirty indicator for all checked
out/updated files by the CVS provider.