Bugzilla – Full Text Bug Listing
| Summary: | File Content Conflict is not handled properly | ||
|---|---|---|---|
| Product: | [Tools] Target Management | Reporter: | Samuel Wu <samuelwu> |
| Component: | RSE | Assignee: | David McKnight <dmcknigh> |
| Status: | RESOLVED FIXED | QA Contact: | Martin Oberhuber <mober.at+eclipse> |
| Severity: | normal | ||
| Priority: | P3 | CC: | dmcknigh, wagnross |
| Version: | 3.2 | ||
| Target Milestone: | 3.3 M6 | ||
| Hardware: | PC | ||
| OS: | Windows XP | ||
| Whiteboard: | |||
| Bug Depends on: | |||
| Bug Blocks: | 337852 | ||
| Attachments: | |||
|
Description
Samuel Wu
Created attachment 187201 [details]
patch to make the editor dirty on unresolved upload conflict
Created attachment 187202 [details]
patch to make the editor dirty on unresolved upload conflict
Samuel, could you try with this patch? Thank you for the prompt response, Dave. Can you please check for ITextEditor instead of AbstractTextEditor. It's a bit too restrictive. The problem was fixed until step 6 as in the problem scenario. I re-wrote it as the following. 6. Close the file with pending changes. Choose no when being asked whether to save the pending changes. Reopen the file 7. When Local Changes Pending dialog comes up, choose to Open editor with pending changes. 8. The file is opened with the pending change but the file is not marked as dirty and the pending change can't be saved 9. If the action Save as is run, the Eclipse project browse dialog will be brought up which can't save the file either 10. Make another change to the file 11. Shut down eclipse 12. Eclipse notices the pending change and asks whether to save 13. Click Yes to save the change 14. Restart the eclipse 15. The file is not marked as dirty and the pending change is not saved to the original file Created attachment 187217 [details]
updated patch with handling for reopen
I've updated the patch to mark the editor dirty on reopen of a file that we've marked as dirty.
The new patch moves forward and it fine until step 11. RSE used to pop up a content conflict dialog if the user chooses to save the file. It doesn't do that any more. 11. Shut down eclipse while there is a pending change in the file. 12. Eclipse notices the pending change and asks whether to save 13. Click Yes to save the change (no RSE prompt for conflict content) 14. Restart the eclipse 15. The file is not marked as dirty and the pending change is not saved to the original file (In reply to comment #6) > The new patch moves forward and it fine until step 11. RSE used to pop up a > content conflict dialog if the user chooses to save the file. It doesn't do > that any more. > > 11. Shut down eclipse while there is a pending change in the file. > 12. Eclipse notices the pending change and asks whether to save > 13. Click Yes to save the change (no RSE prompt for conflict content) > 14. Restart the eclipse > 15. The file is not marked as dirty and the pending change is not saved to the > original file This last issue is a little tricky because, when Eclipse starts up with an open editor, RSE doesn't create the corresponding SystemEditableRemoteFile wrapper until it receives a change event. In order to resolve this, I suppose we could have RSE to automatically create wrappers for the appropriate open editors at startup although there's the possibility that the RSE plugins might not be loaded yet and I don't think it's a good idea to force the activation of RSE. The compromise may be to have the temp file listener create the wrappers when it gets loaded - so the dirty editor would only be seen when RSE is loaded. When there is a pending change in editor and the user choose to shut down, the edito prompts for saving the file. If the user choose to cancel it, the editor will actually cancel the shutdown process. Is it possible for RSE to do something similar to handle the content conflict? Then we don't need to worry about the start up. Created attachment 188067 [details]
updated patch allowing remote save during shutdown if connected
(In reply to comment #8) > When there is a pending change in editor and the user choose to shut down, the > edito prompts for saving the file. If the user choose to cancel it, the editor > will actually cancel the shutdown process. > Is it possible for RSE to do something similar to handle the content conflict? > Then we don't need to worry about the start up. The latest update to the patch should deal with the save case during shutdown so long as the associated subsystem is connected (the remote save should go through). If not, then we still don't have the dirty flag on the editor. As far as I can tell, we can't halt the shutdown process like it's done for the editor cancel. Created attachment 188341 [details]
updated patch with handling for some special shutdown cases
Hi Dave, The following scenarios failed for the latest patch. 1. Replace with remote copy after Cancel 1.1 Open a file in an editor and make a change 1.2 Touch the file on the remote host to create a conflict 1.3 Click the Save button and conflict is found. 1.4 Cancel the conflict dialog 1.5 Click the Save button again 1.6 When the conflict dialog comes up again, select to replace the content in the editor with the remote file 1.7 The file is still marked as dirty in the editor with the pending change and the remote file still contained the old content 1.8 Click the Save button for the third time 1.9 The pending change was written to the remote file without any prompt 2. Pending change is lost 2.1 Open a file in an editor and make a change 2.2 Touch the file on the remote host to create a conflict 2.3 Click the Save button and conflict is found. 2.4 Type a new file name in the file name field and save it. The file is not marked as dirty any more 2.5 Close the editor 2.6 Reopen the file and the pending change could not be found 2.7 Refresh the directory and the new file couldn't be found either 3. Hangs when shut down 3.1 Open a remote file in the editor and make a change 3.2 Touch the file on the remote host o create a conflict 3.3 Shutdown workbench 3.4 When being prompted, choose to save the file 3.5 When conflict dialog comes up, choose to replace the content in the editor with the remote file 3.6 The workbench stays running with the following stack Thread.sleep(long, int) line: not available [native method] Thread.sleep(long) line: 850 SystemTempFileListener$TempFileSaveParticipant.saving(ISaveContext) line: 102 SaveManager.executeLifecycle(int, ISaveParticipant, SaveContext) line: 361 SaveManager$1.run() line: 170 SafeRunner.run(ISafeRunnable) line: 42 SaveManager.broadcastLifecycle(int, Map, MultiStatus, IProgressMonitor) line: 173 SaveManager.save(int, boolean, Project, IProgressMonitor) line: 1108 SaveManager.save(int, Project, IProgressMonitor) line: 1087 DelayedSnapshotJob.run(IProgressMonitor) line: 44 SaveManager.shutdown(IProgressMonitor) line: 1366 Workspace.close(IProgressMonitor) line: 428 ResourcesPlugin.stop(BundleContext) line: 383 BundleContextImpl$2.run() line: 843 AccessController.doPrivileged(PrivilegedExceptionAction<T>) line: 251 BundleContextImpl.stop() line: 836 BundleHost.stopWorker(int) line: 501 BundleHost(AbstractBundle).suspend(boolean) line: 550 Framework.suspendBundle(AbstractBundle, boolean) line: 1097 StartLevelManager.decFWSL(int, AbstractBundle[]) line: 597 StartLevelManager.doSetStartLevel(int) line: 257 StartLevelManager.shutdown() line: 215 InternalSystemBundle.suspend() line: 266 Framework.shutdown(int) line: 690 Framework.close() line: 588 EclipseStarter.shutdown() line: 415 EclipseStarter.run(String[], Runnable) line: 198 NativeMethodAccessorImpl.invoke0(Method, Object, Object[]) line: not available [native method] NativeMethodAccessorImpl.invoke(Object, Object[]) line: 45 DelegatingMethodAccessorImpl.invoke(Object, Object[]) line: 37 Method.invoke(Object, Object...) line: 599 Main.invokeFramework(String[], URL[]) line: 619 Main.basicRun(String[]) line: 574 Main.run(String[]) line: 1407 Main.main(String[]) line: 1383 (In reply to comment #12) > Hi Dave, > The following scenarios failed for the latest patch. > > 1. Replace with remote copy after Cancel > 1.1 Open a file in an editor and make a change > 1.2 Touch the file on the remote host to create a conflict > 1.3 Click the Save button and conflict is found. > 1.4 Cancel the conflict dialog > 1.5 Click the Save button again > 1.6 When the conflict dialog comes up again, select to replace the content > in the editor with the remote file > 1.7 The file is still marked as dirty in the editor with the pending change > and the remote file still contained the old content > 1.8 Click the Save button for the third time > 1.9 The pending change was written to the remote file without any prompt > When I try this, I get the following dialog after step 1.6: "The file <filename> has been changed on the file system. Do you want to replace the editor contents with these changes?" I click "Yes" and the editor gets replaced with the remote content, while the dirty flag goes away. > 2. Pending change is lost > 2.1 Open a file in an editor and make a change > 2.2 Touch the file on the remote host to create a conflict > 2.3 Click the Save button and conflict is found. > 2.4 Type a new file name in the file name field and save it. The file is not > marked as dirty any more > 2.5 Close the editor > 2.6 Reopen the file and the pending change could not be found > 2.7 Refresh the directory and the new file couldn't be found either > This works for me too. In step 2.4, I use the file dialog to quality the path. Are you not qualifying the new file name? > 3. Hangs when shut down > 3.1 Open a remote file in the editor and make a change > 3.2 Touch the file on the remote host o create a conflict > 3.3 Shutdown workbench > 3.4 When being prompted, choose to save the file > 3.5 When conflict dialog comes up, choose to replace the content in the > editor with the remote file > 3.6 The workbench stays running with the following stack > Thread.sleep(long, int) line: not available [native method] > Thread.sleep(long) line: 850 > SystemTempFileListener$TempFileSaveParticipant.saving(ISaveContext) line: 102 > SaveManager.executeLifecycle(int, ISaveParticipant, SaveContext) line: 361 > SaveManager$1.run() line: 170 This works for me; the workbench shuts down completely without any hang. Does this happen consistently for you? The third problem, Hangs when shut down, only happens in my runtime workbench. It can be ignored. An environment has been set up for the other two problems for Dave to investigate. Created attachment 189230 [details]
updated patch with keyhandling for save as and editor focus
The problem with the first scenario turns out to be that the editor was not in focus so the dialog never came up. Once the dialog comes into focus it will come up but it's possible that a user will be confused and might even close the editor without giving it a chance to update. To address this, I've put code in to make the editor come into focus after a replace with remote.
The save as problem is reproduced when the user types the path only (the dialog can't be used). I've added code to handle that case too.
I've committed the changes to cvs. Please reopen if you run into any other conflict issue. Hi Dave, The patch looks fine. Can you add it t the 3.2.2 build? thanks a lot. (In reply to comment #17) > Hi Dave, > The patch looks fine. Can you add it t the 3.2.2 build? thanks a lot. I've opened bug 337852 for the 3.2.x backport. You are introducing Platform non-API use here:
Workbench.getInstance()
This is not acceptable. Please use
PlatformUI.getWorkbench().isClosing()
instead.
Created attachment 189972 [details]
update to use PlatformUI.getWorkbench().isClosing()
Committed the update. Which plugins were affected by this bug? (In reply to comment #22) > Which plugins were affected by this bug? The affected plugins are the following: org.eclipse.rse.files.ui org.eclipse.rse.ui |