Community
Participate
Working Groups
F2 This single defect describes an eclipse-wide issue. My inclination is to address this immediately after 2.0. When importing zips it appears that if the user chooses to overwrite files then the current implementation will first delete the file and next re-create the file. The initial file deletion will cause the SCM to delete its version of the file as well, losing the file's history. Ideally, user operations would call validateEdit as well. A quick tour of the eclipse platform discovered several places where we are doing the delete/create. We should provide an alternate pattern and use it instead. Support for case insensitive drives causes extra deletes on exact matches org.eclipse.core.resources/resources.jar - org.eclipse.core.internal.resources.File.create(InputStream, int, IProgressMonitor) org.eclipse.core.resources/resources.jar - org.eclipse.core.internal.resources.Folder.create(int, boolean, IProgressMonitor) org.eclipse.pde.ui/pdeui.jar - org.eclipse.pde.internal.ui.wizards.imports.PluginImportOperation.createJarPacka gerFiles(IFolder, IFile) Delete during write of output file org.eclipse.jdt.core/jdtcore.jar - org.eclipse.jdt.internal.core.builder.IncrementalImageBuilder.writeClassFileChec k(IFile, String, byte[], boolean) Copy deletes beforehand org.eclipse.ui/workbench.jar - org.eclipse.ui.views.navigator.NavigatorDropAdapter.doCopy(IProgressMonitor, IResource, IPath, boolean) During import first we delete, then we import... (This was the trigger that caused the search) org.eclipse.ui/workbench.jar - org.eclipse.ui.wizards.datatransfer.ImportOperation.deleteResource(IResource) org.eclipse.ui/workbench.jar - org.eclipse.ui.actions.RenameResourceAction.invokeOperation(IResource, IProgressMonitor) Copy & Move both call this method org.eclipse.ui/workbench.jar - org.eclipse.ui.actions.CopyResourceAction.delete(IResource, IProgressMonitor) Copy org.eclipse.ui/workbench.jar - org.eclipse.ui.actions.CopyFilesAndFoldersOperation.delete(IResource, IProgressMonitor)
Noticed a typo, "Copy deletes beforehand" should be: Copy deletes beforehand org.eclipse.ui/workbench.jar - org.eclipse.ui.views.navigator.NavigatorDropAdapter.doMove(IProgressMonitor, IResource, IPath, boolean)
Entered bug 30823 to fix RenameResourceAction
I need to re-summarize based on latest builds in order to understand the remaining outstanding problems.
*** Bug 31883 has been marked as a duplicate of this bug. ***
Prioritizing bugs. This is a long standing issue that is not high priority.
This is probably a duplicate of bug 269067 (which is pri 3). Can we please have this fixed? If a commit is big, it's really easy to lose data (since it will mark a file as "to delete" and then commit that without any warning what is happening).
Bug 269067 is breaking the Mercurial SCM provider with the package explorer, it makes it unusable for copy/paste to a folder with the same name. I have not looked into the details of this, but it's not low priority if this is where the ultimate fix is needed. If I get some time I can investigate this and try to come up with a patch, but if someone here knows better, the work would be appreciated.
(In reply to comment #7) > If I get some time I can investigate this and try to come up with a patch, but > if someone here knows better, the work would be appreciated. Francis, could you prepare a test illustrating the issue?
IResource#copy(..) and #move(..) should centralize the implementation that replaces an existing target. A partial implementation of this is available in WorkspaceUndoUtil, but that's in a UI layer, and it misses correct handling of file encodings (see also bug 67606). As API, I propose a new flag IResource.OVERRIDE, which can be passed by callers of IResource#copy(..) and #move(..). In a first step, this should only be implemented for operations on IFile (see bug 31883 for possible later extensions). If the flag is set and the destination file already exists, the implementation should not delete the destination file and then perform the copy/move, but it should copy the contents of the original file to the destination (bit-wise). Once that API exists, existing clients that implement the override operation with delete/create should get rid of their implementation and use the OVERRIDE flag.
The bug name reads "namespace". Shouldn't that be "workspace"? Or what "namespace" are we talking about here? *confused* Also: Is P5 really the right priority for this? We were hit by this bug once again today and a team member said "They sure don't take data loss seriously".
(In reply to comment #10) > The bug name reads "namespace". Shouldn't that be "workspace"? Or what > "namespace" are we talking about here? *confused* > > Also: Is P5 really the right priority for this? We were hit by this bug once > again today and a team member said "They sure don't take data loss seriously". So you don't know what this bug is about, but you know you hit it today? ;) Basically this bug is about how copy/move should handle the case where the target of the copy/move already exists (after prompting the user that they are sure they want to overwrite). Currently we delete the target and then copy/move the new file into that location. In some version control systems this might cause the VCS to consider it to be a brand new file and start with a fresh revision history. The requirement here is to instead just setContents on the destination file, so that it is never deleted but just gets the new contents. There are a few things that are unclear here that don't help its priority level. First it's unclear which version control systems are affected. CVS for example doesn't care about delete/create and any file at a given path will keep the same version history. Other VCS systems might track a move, and therefore want the destination of the move to contain the history of the *source* of the move rather than the history of the file that previously occupied the destination location. Another angle on this request is to centralize the overwrite logic in one place, since it can be quite complex and currently there are several bits of code in the platform that do this independently. For example if you copy/move and overwrite in the Package Explorer vs. Navigator you don't currently get consistent behaviour. So, this bug isn't about data loss, but about how our implementation of overwrite might affect semantics of VCS version history. I suspect from your comment that you are seeing something else, and you should enter a new bug for it.
> > The bug name reads "namespace". Shouldn't that be "workspace"? Or what > > "namespace" are we talking about here? *confused* > > > > Also: Is P5 really the right priority for this? We were hit by this bug once > > again today and a team member said "They sure don't take data loss > > seriously". > > So you don't know what this bug is about, but you know you hit it today? ;) See comment #6. > Basically this bug is about how copy/move should [...] That's what I'm talking about. Where is the "namespace" here? The data loss happens like this: 1. I rename a file lib-1.jar to lib-2.jar 2. I copy lib-2.jar (the new version) from another project here 3. I commit (Background: I need to preserve the history of lib-*.jar) What happens is that the rename tells VCS "delete old lib-1.jar" + "add lib-2.jar". Step #2 will delete lib-2.jar in VCS and leave the JAR file in the right place. In step #3, the history of lib-1.jar is deleted, lib-2.jar is *not* committed, *not* added and I see *no sign of a pending change*. Committing the whole project will do nothing, "status" will show nothing. I have to manually add "lib-2.jar" to be able to commit it. The history will be lost. Other team members will have odd errors (missing classes) and I'll have a "works for me" problem. So there is data loss. One person in another department uses Eclipse to manage user configurations. She copies/moves files every day so she's affected very often.
Today, I was bitten again by this bug. When Xtend generates Java code which has been added to version control, the next commit will delete the Java file on disk and in the VCS (Eclipse 3.7). This causes all kinds of problems. Can you please fix this bug? Raising to P1/critical.
The priority field is used by devs to prioritize their work. Lowering to P3.
(In reply to comment #13) > Today, I was bitten again by this bug. When Xtend generates Java code which has > been added to version control, the next commit will delete the Java file on > disk and in the VCS (Eclipse 3.7). > > This causes all kinds of problems. Can you please fix this bug? I don't see the connection between that description and this bug. This bug is about whether overwrite is implemented as deleting the destination following by creating a new resource, or by setting contents one the destination file only. Either way has the same net effect on disk so this bug isn't about data loss at all. It's also not clear to me what particular SCM's are affected by this. It appears Mercurial and ClearCase can't handle this. Are you using one of those? In either Git or CVS this will make no difference.
(In reply to comment #15) > > Today, I was bitten again by this bug. When Xtend generates Java code which has > > been added to version control, the next commit will delete the Java file on > > disk and in the VCS (Eclipse 3.7). > > > > This causes all kinds of problems. Can you please fix this bug? > > I don't see the connection between that description and this bug. This bug is > about whether overwrite is implemented as deleting the destination following by > creating a new resource, or by setting contents one the destination file only. > Either way has the same net effect on disk so this bug isn't about data loss at > all. I was directed here from bug 269067. I don't know what the connection is. I just wasted another hour reverting a commit by a colleague who did a "Clean" before comitting and lost half of his files. > It's also not clear to me what particular SCM's are affected by this. It > appears Mercurial and ClearCase can't handle this. Are you using one of those? > In either Git or CVS this will make no difference. I see this in Subversion and Mercurial. Git might work but isn't an option for me.
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. If the bug is still relevant, please remove the "stalebug" whiteboard tag.
