Community
Participate
Working Groups
Build: I20050906-1200 Several times while using this build, I have hit save in an editor but the buffer contents have not been flushed to disk. When this happens, the file on disk has the same contents as the previous save, but the "Save" action is greyed out and the dirty indicator (*) is gone from the editor tab. There are no errors in the log file or on the Java console. The first couple of times this happened, I thought it was an error in the debugger because my breakpoints and stepping were not lining up with the correct code. However, it just happened again, and I opened the same file in Wordpad to discover that the editor contents do not match the contents in Wordpad. Each time this happened, dirtying the editor again and hitting save again would flush the correct contents to disk. I have not been able to reproduce it consistently, but here is what I did the most recent time it happened. 1) Did a search and replace in a Java file (Ctrl+F, Replace All) 2) Hit save. 3) Discovered that I replaced with the wrong thing 4) Hit Undo (Ctrl+Z) 5) Did another search and replace with the correct value 6) Hit Save. The editor now looks correct, but the file on disk still looks like it was in step 2). I will attach a screen shot in case it helps clarify.
Created attachment 26973 [details] screen shot Here is a screen shot when in the bad state. I had done a global search and replace of "file.getAbsolutePath" and replaced with the field "filePath". After saving and seeing the errors, I hit undo and then replaced "file.getAbsolutePath()" with "filePath" (note the extra brackets). Now the Eclipse editor looks correct but in Wordpad I see the old value.
Here's a simple test case to reproduce the problem: 1. open a text file (can be empty) 2. type something of lenght n 3. save 4. undo 5. type something of lenght n (which can differ from 2.) ==> editor is marked as not dirty and hence save does nothing. ==> lost work
This bug is also in R3.1 and R3_1_maintenance but not in 3.0.2.
Dani - let me know if you need help on this. The undo would have restored the prior resource modification stamp, is it possible that the modification stamp was reincremented after the second change, which made it seem as if it were not dirty?....
Is it possible to fix this for R3.1.1?
>Is it possible to fix this for R3.1.1? That's my plan.
Created attachment 27303 [details] Patch which adds (currently failing) test case to UndoManagerTest
The problem is the document's *next* modification counter which is set back upon undo instead being left as is. Fix is ready but needs some more testing.
Committed to HEAD and released into I20050921-0010. If all tests pass and after some more testing I'll backport it into this weeks 3.1.1 build.
Verified in I20050921-0010. Backported to R3_1_maintenance.
Verified using M20050923-1430
*** Bug 104469 has been marked as a duplicate of this bug. ***
