Community
Participate
Working Groups
Build Identifier: I20110613-1736 With both of the following options enabled: 1. Workspace / Refresh using native hooks or polling 2. Launch Configurations / Delete configurations when associated resource is deleted If a change occurs on the filesystem (such as a folder being renamed or moved) then all launch configurations associated with resources within that location are deleted without chance of recovery. This can cause significant user data loss. Bug 233773 states that the default for (2) has changed to false in 3.7. (It was true here - presumably because my old preference was retained after upgrade from 3.6?) I second the sentiments of https://bugs.eclipse.org/bugs/show_bug.cgi?id=233773#c13 I believe the deletion of these files is too dangerous to be performed automatically - even as a preference. It breaks the usability rule that user mistakes should always be able to be undone (and in corner cases where that's not possible, at least prompt for confirmation before performing such an action.) I would suggest removing the auto-delete option and instead have a manual "clean up" toolbar button, so that this handy tidying action can be user-initiated at a "safe" point in time. Perhaps a confirmation dialog would list the configurations to be deleted prior to removing them. Reproducible: Always Steps to Reproduce: 1. Have the two options selected, as described in the 'details' 2. Locate your favourite project in Windows Explorer 3. Rename a key source folder, such as "net" to "net," 4. Say "oops" and press Ctrl-Z (it can be quite quickly) 5. Sob when it dawns on you that all launch configurations really have been permanently deleted.
I agree it would ideal to prompt the user if we are going to delete them. I think something as simple a checkbox list of all the configurations that would be deleted and let the user select the ones (or none) that they want to delete. Reducing the severity and upping importance; the feature works for auto-deleting configurations, we just need to make it more user-friendly.
Am I going insane, or did the option "Delete configurations when associated resource is deleted" (Run/Debug, Launching, Launch Configurations) get enabled after I upgraded to 3.7.1? Quite likely the former. (I was probably testing this ticket and forgot to disable it again.) Anyway, I lost all my launch configurations yet again, after a bad "svn switch" command using the command line. Great... At least I can recover the source files, but not the launch configurations.
Mike, I assume this won't make it into M3?
(In reply to comment #3) > Mike, I assume this won't make it into M3? You are correct, M3 is not going to happen.
This is not going to make it into My either, moving to 4.3
P1 priority means we will not ship Juno without it. Since it is already targetted to 4.3/Kepler I will move to P2 priority.
(In reply to comment #6) > P1 priority means we will not ship Juno without it. Well, strictly speaking, it means we will not ship the release/milestone indicated by the target milestone, and this is Kepler ;-).
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.
This bug has been marked as stalebug a while ago without any further interaction. If this report is still relevant for the current release, please reopen and remove the stalebug whiteboard flag.
This bug was marked as stalebug a while ago. Marking as worksforme. If this report is still relevant for the current release, please reopen and remove the stalebug whiteboard tag.
Hi, sorry for not checking back earlier - Issue still present. I've just confirmed that preference (2.) still executes immediately upon resource refresh, without prompting. NEW INFO: this is despite the following option, found one level higher in the tree, being checked: (3.) Run/Debug > Launching [✓] "Prompt for confirmation when removing a configuration from the launch history" Thus, even doing something like a git-bisect - whether done inside or outside of Eclipse (maybe I'm working on my C++ code in Visual Studio, for example) - can result in launch configuration files in Eclipse being silently zapped. Having said that, having made (2.) default to OFF in Bug 233773 probably went a long way to mitigating this to only affect power-users and preference-tinkerers. -------- IMHO I find that too many "knobs and dials" harms usability - and I could imagine both preferences (2.) and (3.) being eliminated. (YMMV) 2.) As suggested, a manual "cleanup" action that can be executed from the Launch dialog, to zap all configurations that are unused at that point in time, I think would be nicer than: - a pop-up confirmation appearing out of nowhere (say, during that external git bisect.) - the current dangerous behaviour 3.) Yeah, no-one likes extra popup dialogs, but a preference buried in some obscure place is not a great solution either. The user can multi-select (ctrl+click) before hitting delete, so a one-time confirmation shouldn't be that much of a burden. Esp. since there's no Undo.
Thanks for confirming! Will analyze in 4.14.
There should be a dialog before removing the launch configurations, even if the preference is set. If someone can take this up, will be available for review.
Downgrading to normal as preference is switched off by default.
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. As such, we're closing this bug. If you have further information on the current state of the bug, please add it and reopen this bug. 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.
