Community
Participate
Working Groups
If you have a working copy of a compilation unit and you call unit.copy(fragment, null, fileName, true, monitor); whereas fragment is the working copy's package and fileName is the resource name of the working copy's original, the copy fails and destroys the original causing data loss. See bug #8873 for a scenario. The operation should either detect this and abort the operation or handle it properly but not destroy data. Suspect offending code in CopyResourceElementsOperation.processCompilationUnitResource: ... if (destFile.exists()) { if (fForce) { // we can remove it deleteResource(destFile, false); } else { // abort throw new JavaModelException(new JavaModelStatus(...)); } } if (this.isMove()) { sourceResource.move(destFile.getFullPath(), fForce, true, getSubProgressMonitor(1)); } else { sourceResource.copy(destFile.getFullPath(), fForce, getSubProgressMonitor(1)); }
Problem identified. When resolving single names, we did set the depth incorrectly (during each iteration of the loop through enclosing scopes) instead of when returning the found file only. Fixed, regression test added (will go into next integration build).
Oops, comment went to wrong bug report, ignore my previous post.
You localized the error. But what do we want to do? Failed with a NAME_COLISION. What I don't like is that the UI is checking if the file already exists and the JavaModelOperation does the same thing. If the user said that he wants the file to be overriden, we should save the new contents. We can silently handle this case by saving the new contents. Then I don't understand what this code is doing in CompilationUnitEditor.performSaveAs: /* * 1GF5YOX: ITPJUI:ALL - Save of delete file claims it's still there * Changed false to true. */ getDocumentProvider().saveDocument(monitor, newInput, getDocumentProvider().getDocument(getEditorInput()), true); I think this is the responsability of the java model operation to update the contents of the file if necessary. Any comment?
I changed the code to simply set the contents of the existing file to the new contents in case you do a saveas on the same file. There is no mode added deltas propagated after this operation. If you are not in a mode you want to override the existing file, I throw a NAME_COLISION error. Is this behavior acceptable for you? If yes, I will release it for the next build (tomorrow's build if you reply quickly).
Fixed and released in HEAD. Hopefully this will be the behavior you expected.
