Community
Participate
Working Groups
Created attachment 185944 [details] Screenshot showing the issue Build ID: Eclipse 3.6.1 on RHEL WS 5 CQ:WIND00248891 1. Create a project ("prout") 2. Create a file in the project ("linkSyms.c") 3. Open the file in editor and add text but do not save 4. Outside Eclipse, create another file in the project folder 5. Delete the project --> I couldn't reproduce the described issue, since unsaved changes are reported as a warning only for me --> But a tester managed to produce attached dialog on RHEL-WS5: unsaved changes are considered a fatal error. Due to the fatal error, the "Continue" button is missing from the dialog. Still, the dialog message prompts to press the continue button: Delete Resources A fatal error occurred while performing the refactoring. File 'prout/linkSyms.c' has unsaved changes. 'prout' contains resources that are out of sync. Press continue to force delete Suggested change: A message like "contains resources that are out of sync" should not make assumptions about the dialog in which the message is being displayed. The "Press continue to force delete" text should simply be removed from that message. It would be architecturally more correct if the DIALOG produced that hint for the user, and not the message.
I also think it is incorrect to not allow deleting a project when the user asked to, even in case of fatal errors. Users should ALWAYS be able to remove a project from the workspace if they want to.
Moving to UI to comment.
Created attachment 185945 [details] Delete with Continue button I'm getting the Continue Button. I could also see that unsaved changes is just a warning in my case and not an error as in the original screenshot. I suspect that CDT has some delete hooks which makes it an error. Martin, Do you get the Continue button when you try with the General project & a normal text file instead of the C file?
If that matters - I'm on a 3.7 I-build, didn't try this on 3.6
As I mentioned, I also couldn't reproduce the original problem (tried 3.6.1 on Win7 as well as RHEL5). Like for Prakash, I'm also getting a "warning" only instead of an error, thus the Continue button is there and it's not an issue. I have asked the original submitter for more detailed steps to reproduce. But IMO not knowing how to reproduce doesn't make a difference in that there are two architectural problems IMO: - An error message should not make assumptions about the dialog/context in which it is shown - Deleting a project from the workspace should always be possible, even in case of fatal errors.
This seems like it belongs to the LTK/UI.
> - Deleting a project from the workspace should always be possible, even in > case of fatal errors. Not really. Assume the project is on an USB stick which you took out of your laptop. I wonder how we should delete in such a case ;-) This bug is pretty vague. I suggest to provide more detailed steps or the exact problem that is faced and then reopen it again.
(In reply to comment #7) > > - Deleting a project from the workspace should always be possible, even in > > case of fatal errors. > Not really. Assume the project is on an USB stick which you took out of your > laptop. I wonder how we should delete in such a case ;-) I think Martin in this case meant remove the project from the workspace (so that org.eclipse.core.resources no longer knows about it) and not necessarily physically delete the files. I would find that useful myself anyway.
(In reply to comment #8) > (In reply to comment #7) > > > - Deleting a project from the workspace should always be possible, even in > > > case of fatal errors. > > Not really. Assume the project is on an USB stick which you took out of your > > laptop. I wonder how we should delete in such a case ;-) > > I think Martin in this case meant remove the project from the workspace (so > that org.eclipse.core.resources no longer knows about it) and not necessarily > physically delete the files. I would find that useful myself anyway. That's another topic. The workspace might also be on the USB stick. All I'm saying is that "always be possible" can't be achieved.
Thanks Remy, that's exactly what I meant. My point is, I might have selected the project and pressed "delete" in order to get rid of some error condition. It doesn't make sense to deny this "unregister from workspace" operation due to errors (provided that the workspace itself is writable). See also bug 333437 for a reproducable case to provoke a state where I cannot delete an item. I don't know in what way Resources, UI, LTK, Refactoring and Undo history play together here. But as an end user, my request is clear and simple ("Get rid of the item I selected"). It's annoying that this request is denied, and it's even more annoying that I'm prompted to perform an operation that I cannot perform ("Press Continue").
(In reply to comment #10) > See also bug 333437 for a reproducable case to provoke a state where I cannot > delete an item. That was a different problem and has been fixed with bug 300368 comment 13 ff. We can look at the problem from comment 0 again if you have steps to reproduce.
> We can look at the problem from comment 0 again if you have steps to reproduce. Hi Markus :) I was able to reproduce the problem with Eclipse 3.7 on my linux host, wcan we reopen the bug and get this addressed? Here is what I did: 1.) Start Eclipse 3.7 with a new Workspace 2.) Create a simple project: "test" 3.) Create a simple file: "test.c" 4.) Edit the file in Eclipse, do not save 5.) Edit the file outside Eclipse, do not save 6.) Delete the project, ignoring Eclipse dialog that wishes to synchronize/save the file 7.) See attached picture.
Created attachment 205054 [details] press continue message
(In reply to comment #12) > > We can look at the problem from comment 0 again if you have steps to reproduce. > Hi Markus :) > I was able to reproduce the problem with Eclipse 3.7 on my linux host, wcan we > reopen the bug and get this addressed? > > Here is what I did: > 1.) Start Eclipse 3.7 with a new Workspace > 2.) Create a simple project: "test" > 3.) Create a simple file: "test.c" > 4.) Edit the file in Eclipse, do not save > 5.) Edit the file outside Eclipse, do not save > 6.) Delete the project, ignoring Eclipse dialog that wishes to synchronize/save > the file > 7.) See attached picture. I can reproduce this on my Windows 7 box BUT in step 5 I have to save.
When me make the error non-fatal, we have to make sure that the dirty editor behaves properly after the user continued. Best would be to close it without saving.
(In reply to comment #14) > (In reply to comment #12) > > > We can look at the problem from comment 0 again if you have steps to reproduce. > > Hi Markus :) > > I was able to reproduce the problem with Eclipse 3.7 on my linux host, wcan we > > reopen the bug and get this addressed? > > > > Here is what I did: > > 1.) Start Eclipse 3.7 with a new Workspace > > 2.) Create a simple project: "test" > > 3.) Create a simple file: "test.c" > > 4.) Edit the file in Eclipse, do not save > > 5.) Edit the file outside Eclipse, do not save > > 6.) Delete the project, ignoring Eclipse dialog that wishes to synchronize/save > > the file > > 7.) See attached picture. > > I can reproduce this on my Windows 7 box BUT in step 5 I have to save. Thanks Dani, yes, step 5 needs to save the changes, sorry for that :( Helmut
(In reply to comment #15) > When me make the error non-fatal, we have to make sure that the dirty editor > behaves properly after the user continued. Best would be to close it without > saving. Thanks Markus for reopening this one! :)
Making the error for the dirty file non-fatal is trivial: Just use replace addFatalError in DeleteResourcesProcessor#checkDirtyFile(RefactoringStatus, IFile). The closing of the dirty editors is a bit more work. This will probably go into DeleteResourceChange#perform(IProgressMonitor), where the visitor should also run if the resource is not accessible. Hint: Call IResource#accept(..) with IContainer.DO_NOT_CHECK_EXISTENCE and do the proper handling for each dirty editor individually (save if present, discard if not present).
Is there an update on this bug? I am using Mars.2 Release (4.5.2) and I encountered this today. I messed up one of my java project setup (my src/main/java and src/main/resources now appeared as src only and all my java classes complain mismatched package names of main.java....). I decided to delete the project (including removing all the files) and re-import it from our version control will be the quickest way to fix this. The delete operation gave me that fatal error about a file in the build folder has unsaved changes. I don't remember editing this file in the source folder; so that chance that I have this file opened in the build folder is even less... Just for reference, the error is: File'pdk-design-manual/build/classes/main/resources/parseRules/15_category_geometry.xml' has unsaved changes. Regardless, I don't see why it won't let me continue for a delete operation especially when I included the "remove content" option.
(In reply to Chung Ley from comment #19) > Is there an update on this bug? Help is welcome.
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie.
