Community
Participate
Working Groups
dataloss I tried to move an Eclipse-manages source directory on the harddisk. To achieve that, I tried to 1. Remove the directory from the project in Eclipse using the context menu of the dir and choosing "Delete". 2. Manually move the dir using the shell 3. "Import" the new dir into the Eclispe project. 2. failed, because Eclipse deleted my source files in step 1, without warning. Several hours of work are lost. *angry* Actually, 1. already had errors with some "out of sync" files. Separately "deleting" the remaining files worked. I expected step 1 to remove the files just from the Eclipse project, *not on the harddisk*, because that's what "Delete" does for "Import"ed directories/files. In fact, "Delete" is the only way (I could find) to undo an Import, but leave the files on disk. The files which got deleted accidently have been created using the Eclipse UI. Concrete suggestions: 1. Before deleting any source files on disk, warn me! (with option to disable it, explaining precisely for which cases the option applies) 2. Add a "Remove from Project" command, to delete resources from the Eclipse project and let Eclipse stop to manage them, but to leave them on the disk where they are. 3. Rename "Delete" into "Physically delete files". 4. Make Imported and Eclipse-created resources behave the same or at least consistently.
haha, found in a sig on <http://kerneltrap.org/node.php?id=542>: > Real Programmers consider "what you see is what you get" to be just as bad a > concept in Text Editors as it is in women. No, the Real Programmer wants a "you > asked for it, you got it" text editor -- complicated, cryptic, powerful, > unforgiving, dangerous. Add inconsistent to that ;-P (Obviously, I disagree, but it's funny nevertheless.) Oh, and I today noticed that in my Java Project, an Import seems to *copy* the files and then consequently physically delete them (with a warning, but not explicitly saying that the files are physically deleted on the disk). I don't know anymore, what happenes in which case (Importing a whole project, importing dirs from the File System, creating files using Eclipse; Java vs. C++ vs. Simple project).
The source directory deletion issue is also reported in bug 20422. Assigning for further comment on importing resources.
Moving around directories within your workbench directory outside of Eclipse is a dangerous thing to do - your memtadata will end up out of synch and you can easily get yourself into an inconsistent state. There are several features in Eclipse that can help you out if you have done this and need to attempt to recover from it 1) F5 refresh from local done at the project level will update the contents of your project to what is currently on disk. It won't help you with any classpath problems you have created - you will have to fix that yourself. 2) If you have deleted or copied a project to another location use Import-> Existing Project and that will set it back up for you. Import doesn't do a deletion and now explicitly prevents importing from a location that is currently within one of the projects you have loaded. When you say that it deleted source files without warning do you mean that no dialog at all came up or that only the one for the directory did? If none came up please provide steps as this is a bug. Also note that resources in Eclipse are elements on your file system - if you choose to delete them you also delete thier physical representation. I am going to mark this as WORKSFORME - please reopen if you have some other issues that I missed that require addressing.
> Moving around directories within your workbench directory outside of Eclipse > is a dangerous thing to do - your memtadata will end up out of synch and you > can easily get yourself into an inconsistent state. That's not what I tried to do. Please read the initial description. I tried to remove it from Eclipse first, then manually move, then readd it to Eclipse. But the removal from Eclipse *deleted* the files, there was nothing to move anymore. It was not just "dangerous", because I got into an inconsistent state, I in fact inrevokably lost the only copy of these files. REOPENing > When you say that it deleted source files without warning do you mean that no > dialog at all came up or that only the one for the directory did? I don't remember anymore, it's now 2 days ago. In any case, the dialog doesn't tell me that the files are removed *physically*, *on the harddisk*. As I said, in other cases, a delete just removed it from the project, not on the disk, and "delete" was the only way to do so, so I thought that "delete" just refers to deleting from the Eclipse UI and project files, not the source files on disk. > Also note that resources in Eclipse are elements on your file system - if you > choose to delete them you also delete thier physical representation. As stated above, that's not the case always. Also, how do I then undo an Import? If I once imported some files, but no longer want to have them in my Eclipse project, but still need the filels on my disk, how do I do that, then? I found no way.
That is the correct behaviour - if you delete from Eclipse you delete from the filesystem as Eclipse gets its structure from the filesystem (supplemented by extra info in the metadata). You also cannot undo an import or a delete. We can change this a PR to a feature request for that functionality if you like.
We have 3 issues here, then: 1. The "correct behaviour" of physically deleting, as you state, does not happen in all cases. 2. The user is not made aware of the massively severe and destructive nature of the action he chose. 3. We has to be a way to undo an Import. That's what I tried to do and how I got into the problem. File then as different, blocking bug or track them all here, it doesn't matter, but they are all parts of what caused my dataloss.
The only case where physical deletion does not occur is if you choose to not delete contents of a project when you delete it. I don't think there is another case and if there is we need to be more explicit about it. Renaming PR.
I don't remember in which exact cases delete didn't delete files from disk. I files bug 29034 about the UI of delete.
There are currently no plans to work on this feature
The original report was a severe dataloss bug, where I lost significant work. You continued to morph it, ignored it and now WONTFIX it. If you think that the bug cannot happen anymore in current builds, please explain why, e.g. by bug 29034. "The user did the wrong thing" is not an appropiate response in this case, because it involved severe dataloss, and it's the application's duty to prevent that even in face of mild misconceptions on the side of the user. Please also explain what I should have done in that given situation when moving directories within Eclipse is not practical, e.g. because of the VCS or the amount of files.
When I delete a project, it asks me if I want to also want to delete the contents from the hard disk. Doesn't this provide the behaviour you're looking for? Also... your original problem was to change the physical location of the project on disk. You can do this by highlighting the project and selecting "Refactor > Move...".
There are several cases: - Whole project - Only a subdirectory (or file) (This was the case in this bug, IIRC) And, orthogonally: - Imported - External dir, and kept it there - Copied into workspace dir - Existing project (external and in workspace) - Created in Eclipse - Java - C++ - Simple project IIRC, there are other factors, but I can't remember right now. At least some of these factors influence Eclipse' behaviour, and it's *not at all* clear to the user which and how.
The simple rule is: "Delete" will ask the user to confirm and will then delete the files or folders from the workspace, and thus also from disk. Deleting projects is a special case where the confirmation dialog asks if the corresponding files and folders on disk should be kept rather than deleted. For performance reasons, Eclipse is not always in sync with the contents on the file system if changes are made using external tools. If this is the case and you try to do anything from Eclipse (including deleting files), the action from within Eclipse may fail. To avoid this, you can choose to "refresh automatically" by checking the corresponding preference under General->Workspace. What are you suggesting we should do to avoid confusion? Would it help if we improved our documentation?
> What are you suggesting we should do to avoid confusion? Make it very clear, in the UI, where you want to delete from - workspace or disk. Very different thing. Maybe use "Remove from workspace" versus "Delete from disk", but the works "workspace" and "disk" (or similar) must appear to disambiguate. *Always* give an option to remove from workspace only, but not from disk. I had a usecase for this, and IIRC this was causing my problem in the first place. If this is outright impossible due to how Eclipse works (disk is authorative list for workspace), then make explicitly state this in the dialog, like "Because the workspace is just a view of the disk, you cannot remove from workspace without deleting from disk, so if you want to remove the files from your workspace, but keep the files, you need to make a copy now, using external tools, *before* clicking 'Delete' here." (a bit long, but you get the point). Documentation or comments here in the bug explaining how Eclipse works do not help, nobody reads that. It needs to be embedded in the UI, some way or the other.
There is no "remove from workspace" operation for files or folders. Deleting will always delete the file(s) from disk. It is possible to create a linked folder or file in Eclipse that just points to a folder or file in the file system. Deleting the link will not delete its target, but deleting a file within a linked folder will indeed delete that file from disk. The UI shows linked files and folders differently, and uses a different confirmation dialog when deleting a link. Note that Eclipse now has undo support, which would have prevented the data loss that made you file this bug. So overall, it seems to that Eclipse does not explain well enough what a workspace is, and how it relates to what you find on disk. Furthermore, the wizards for importing a project into Eclipse are a source of confusion. We are aware of these problems but don't have any concrete short-term ideas for how to improve the end user experience. Can we mark this bug as fixed? Eclipse 3.3 would not cause data loss in the scenario you describe.
> Deleting the link will not delete its target, but deleting a file > within a linked folder will indeed delete that file from disk. Ah! That's of course *begging* for user confusion and catastrophes like mine. Esp. if you call both "Delete". (FWIW, in Visual Studio, I'm told that the file list in the project is manually managed and not all files in the directory show up, and you can remove files from the view without deleting the files. Just FYI.) > The UI shows linked files and folders differently, and uses a > different confirmation dialog when deleting a link. Well, an icon is easy to miss. I don't know the exact, current dialogs, but if you call both "delete", are both just normal warning dialogs, then the user won't notice the difference, think "yeah, I know that", click it away, not noticing that it's now a completely different dialog. You need to be jumping eyecatchingly clear in the delete confirmation about "delete from disk". Make it red or with bomb animation ;-). And do *not* warn, or at least have a very different, far less dramatic dialog, when you merely remove from workspace. > So overall, it seems to that Eclipse does not explain well enough what a > workspace is, and how it relates to what you find on disk. ... > We are aware of these problems but don't have any concrete > short-term ideas for how to improve the end user experience. Well, I just made some *very* concrete suggestions. > Can we mark this bug as fixed? No, nothing actually changed for this bug. Undo is just a workaround which *may* help recover from a catastrophe, but not prevent it form happening. This bug is not fixed unless the most frantic and hectic and confused user would realize that he's deleting files on disk when removing them from workspace (and when not).
(In reply to comment #14) > > What are you suggesting we should do to avoid confusion? > > Make it very clear, in the UI, where you want to delete from - workspace or > disk. Very different thing. Maybe use "Remove from workspace" versus "Delete > from disk", but the works "workspace" and "disk" (or similar) must appear to > disambiguate. I fully agree with this! (In reply to comment #14) > There is no "remove from workspace" operation for files or folders. But for projects, right? Currently I have to remove projects from my workspace via "Delete" which is a very very bad term for it as I don't want the content lost ...
Going thru the comments: (*) Delete simply deletes a file/folder (it won't be in the workspace or disk). Its a safe operation as you can still right click and do a "Restore it from the Local history" (*) If you want to "Remove from workspace" but leave it on disk option for file/folder, you have to use the Resource Filters (introduced in 3.6) (*) Deleting a project is different. It can simply remove from the workspace or can remove from the disk as well. So the dialog is shown. Removing from the disk is dangerous, as there is no restore option But I agree, that we could still have a "Remove from workspace" menu item, which adds it to the exclusion filter if its a file/folder, or simply deletes from the workspace if its a project. Delete will continue to remove the resource both from workspace & disk (additionally shows a warning in case of a project)
*** Bug 336643 has been marked as a duplicate of this bug. ***
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.
> (*) Delete simply deletes a file/folder ... Its a safe operation > as you can still right click and do a "Restore it from the Local history" Delete is always a dangerous operation and never "safe". You have no idea in which state the file is, or whether my history is properly saved etc.. > (*) If you want to "Remove from workspace" but leave it on disk option > for file/folder ... yes, that's what this bug/enhancement is about. > you have to use the Resource Filters (introduced in 3.6) That doesn't cut it. I want to just right-click and remove it from the workspace list, without deleting the file from disk.
There are many reasons for wanting this: * Artifact files that need to be on disk, but are not source, and I don't want to see them. * Files needed for technical reasons, e.g. settings files from various text editors or IDEs, which I will never edit manually and which are just disturbing. * Many more cases
So what we want now is something to easily click on a file/folder in the Navigator (etc.) and have it excluded from the parent?
Yes. See initial description (comment 0), "Concrete suggestions". "Physically delete" and "Remove from project" should be 2 separate commands, and be worded consistently like this, independent from the situation, whether the files are linked, imported, or part of the project in the same directory on disk.
