Community
Participate
Working Groups
There have been lots of fresh reports of "Bug 353379 - Undo/redo in java editor causes unrecoverable file corruption" since May 2012. However, there's no feedback from Eclipse team since then. I suspect it is being overlooked because the issue is "RESOLVED WORKSFORME". Originally the issue was one reporter and one developer, but with numerous reports I don't think an individual "Works for me" really sticks anymore. It may be something that is only easy to see in real-world use. I'm opening a new issue to ensure that this is acted upon, as there is definitely an issue, and extremely serious one. Irreversibly corrupting work is about as bad as it gets. Please do not close this issue as a duplicate until 353379 is reopened!
In which version do you see it? Is there anything in the .log? Can you provide steps to reproduce it or help in any other way to debug/fix it?
I'll try to, but the original bug has lots of new logs and information already...
(In reply to Robert Platt from comment #2) > I'll try to, Yes, please. > but the original bug has lots of new logs and information > already... Yes, but no steps.
> > but the original bug has lots of new logs and information > > already... > > Yes, but no steps. Well, there are many efforts to provide steps in a number of comments; clearly there is more to it, since not everyone can follow those steps and see the bug. I've working on a cut-down project to reproduce this, and will even video it when successful, but starting I haven't reproduced it as a minimal project so far -- I need to try a adding back in whatever else I'm using (egit, maven, aspectj...) Needless to say this is slow going and I have many other demands on my time. BUT the important thing is that this bug not be closed just because it is difficult to isolate. I'm willing to do my best, I just ask the Eclipse dev team to respect that this bug is REAL.
It's a race condition - and those are difficult if not impossible to reproduce - you know that Undo redo is interrupted by building workspace or organize imports or whatnot and once in a while boom.
Absolutely, but it seems that unless somebody provides a test case written in blood, nothing is going to happen :-(
(In reply to Robert Platt from comment #4) > BUT the important thing is that this bug not be closed just because it is > difficult to isolate. I'm willing to do my best, I just ask the Eclipse dev > team to respect that this bug is REAL. Yes, we can keep it open and help to reproduce it is very welcome, since we never ran into it so far, which would allow us to debug the problem. Can you answer the following questions: - In which version do you see it? - You say "Irreversibly corrupting work" You can get the previous version(s) of the file from the local history. Did that not work?
Sorry, we can't do anything without further information.
Hi Dani, I think this has got confused. Information about steps to reproduce were provided in the original bug #353379. As commented there the issue was observed in 4.4. The reason this new issue was opened was because I couldn't reopen the original issue myself, and there was no evidence that the Eclipse devs were looking at the comments on an issue marked "RESOLVED WORKSFORME". If this new report is where new comments should go, that is fine, but even so the previous comments for the original bug report should be taken into consideration before changing the status of this issue. Regards restoring from local history, this can only recover changes that have been saved. Last time we had this during real work, we were pair programming during a major refactor, we hadn't actively saved much, so the local history wasn't much use. That provides the further information requested.
As a general point, the problem we have is that the workaround is to disable the feature in eclipse which is related to the issue: reformatting on save. There is no evidence that Eclipse corrupts even with that feature disabled. This workaround prevents the issue. It is too risky to use the save reformatting feature in a real project on a day-to-day basis. You won't find many volunteers masochistic enough to have their real work corrupted at a random point just to reproduce this bug and prove it still exists -- especially as the issue has now been thoroughly described by several different users IMHO (in the original issue). I think you have to use the feature in the real world for a while before marking that this works for you. So the question to the Eclipse devs: do you use automatic reformatting on save on a daily basis, i.e. do you use these Eclipse features, and have you used it for real-world refactoring? If a few Eclipse devs do so for a month or two and still no sign of the issue, then I can support marking this resolved again...
(In reply to Robert Platt from comment #10) > So the question to the Eclipse devs: do you use automatic reformatting on > save on a daily basis, i.e. do you use these Eclipse features, and have you > used it for real-world refactoring? If a few Eclipse devs do so for a month > or two and still no sign of the issue, then I can support marking this > resolved again... Robert, I did what you outlined in bug 353379 comment 25. I have over two hundred projects in my workspace and tried several times (formatting all, and also formatting only edited lines), plus I have format edited lines on save enabled during my daily work. Most Eclipse projects/devs in the top-level project (the SDK), have format edited lines on save enabled, and some even have that stored in their project settings. Leaving this bug open sends the wrong signal: other people will think that the bug is open, and will get some attention, but it won't. However, if it is closed, and someone sees the same problem he might add some steps.
What refactoring steps did you try?
(In reply to Robert Platt from comment #12) > What refactoring steps did you try? For the concrete tests I used rename (type and method) and inline. But during my work I use many of the existing refactorings.
Right, now that's a lot clearer and I feel a bit more confident about this being marked resolved. I've just spoken to a colleague, they've been using the feature successfully with 4.4.1. Who knows, maybe this fixed it -- we'll monitor and see. In terms of sending the wrong signal with an open bug report, I understand your reasoning but I'm not so sure you want people to think a long-standing issue isn't getting attention. I think that just annoys people, especially if there is no response. If you see in the original #353379 you'll understand why I've been hesitant to close this again: - Palmer Eldritch October 2013. Reopen this please as it is certainly an issue... [followed by detailed report] [No Response] - Nicolas Bros October 2013. I'm seeing the same issue on Kepler SR 1 (Build id: 20130919-0819) I already opened Bug 332653 for this a long time ago... [No Response] - M F September 2014. It's near end of 2014 and this bug still exists. Hard to reproduce, but certainly an existing bug. And as this is annoying as hell it really needs to be fixed... [No Response] - Nicoloas Bros September 2014. I can confirm the issue still exists. When I undo redo many changes quickly the buffer often gets corrupted... [No Response] This ended with me opening a new issue and pestering you ;-)
