Community
Participate
Working Groups
When I delete a file from the workspace, either programmatically or manually, and then replace the file, Eclipse seems to get kind of stuck with the old file. Let me elaborate. I have a multipage editor with separate pages for different files. If I delete one of the files, the associated page is removed. If I replace the file (same name, different content) I get my page back, but it displays the contents of the old, deleted file. If I have the file open in its own editor (default text editor) and delete the file, the editor is closed. If I replace the file (as above) then open the editor, I get a popup message telling me that the file has changed on disk, and do I want to reload the file. I'm wondering if there is a way to "force" eclipse to reload the file from the file system without having to have a dialog (or in the case of my own multipage editor, not having any way to reload the file). I have the "Refresh workspace automatically" turned on already. I will attach a zip file containing a .avi file demonstrating what I mean.
Created attachment 18034 [details] Zip contains video (.avi) file demonstrating problem In the demo, the workbench starts up with an editor open. The editor contains pages for multiple files. A change is made in the primary file (cruise.mvs) and then the launch is run. The launch causes the output file (cruise.mvs.lis) to be deleted and then a new one is created in its place. The change in the primary file is reflected in the echoed content of the output file (cruise.mvs.lis). The editor is closed and then reopened. A change is made to the primary file (cruise.mvs) and the launch is run again. The change is not reflected in the output (cruise.mvs.lis) file until opening it in its own editor. Then a popup is displayed asking the user to reload the contents from disk. Then the file is updated in both the text editor and in the multipage editor.
This is an issue with synchronization between the editor's in-memory representation of the file with the file contents on disk. I suspect your editor can be customized to automatically load the changed contents from disk without prompting if that is the behaviour you are looking for. Moving to text for further comment.
The editor that is being used is eclipse's text editor. In one case the user opens the file separately in the default text editor, in the other, an instance of TextEditor is embedded as a page in a multipage editor. It appears that eclipse itself (or the default text editor) keeps a cache of the file. These are new instances of the editor in each case, so it must really be the workbench/resources that is keeping the cache. This only occurs when the file is deleted and then replaced, not when the contents are just overwritten. And the funny thing is, as demonstrated by the video, is that the first time the file(s) are opened, everything works fine. Its only after the file(s) have been opened, then closed, then opened again. I've tried to debug the problem to see if I could find anything, but I have not had any real success. Every time I debug, I think I interfere with the system enough for things to work properly, because it always seems to think the file is in sync with the disk (but maybe that's all in my head).
Which build? To me this looks like the embedded text editor doesn't get closed correctly in which case the underlying document (and file buffer - depends on which build you use) is still connected to the file path. If you open the same path again the old document is shown. Is the following preference enabled? Workbench > General > Refresh workspace automatically In order to debug this we either need a test case based on Eclipse SDK or you need to provide us a simple version of your multi-page editor that demonstrates the problem.
I'm not sure what you mean by "closed correctly". When the page containing the TextEditor is removed from the multipage editor, the editor is disposed. This all happens through the FormEditor/MultiPageEditorPart#removePage(int) method which invokes the disposePart(IWorkbenchPart) method. Is there something else I should be doing? As far as a test case goes, I'll see if I can come up with something.
Correct: if dispose() is called then the document provider should get disposed as well (unless there's some error inbetween - log entries?). I just named a possible cause since I don't have enough information to tell more.
I am attaching a zip file containing my plugins (with source). I was not able to conjure up a simple test case, so I am providing my plugins as-is. I will also attach 3 text files that will be opened by my multipage editor. With all of this, you should be able to actually run and see what I see.
Created attachment 18177 [details] Contains deployable plugins and fragments with source.
Created attachment 18178 [details] Data file
Created attachment 18179 [details] Namelist file
Created attachment 18180 [details] Tables file
Thanks plug-ins. Where do I have to put the three test files?
You can just import them into your runtime workspace (where the plugins are running). Then you should just be able to double-click any one of them to open the editor. Once the editor is open, you should create a KADRE launch, using the launch configuration dialog. We may have changed the settings in the launch to avoid the problem for now, so go to the Output tab/page of the LCD and make sure the Clear option is selected under Existing Files. Then run. You may have to run once before you can see the problem, since the first run will create the output files, and subsequent runs will clear and then replace the output files.
Investigate during RC2.
Note: the attached plug-ins cannot be compiled or run due to unmet dependencies: - com.tsccos.utils - org.jfree
cannot reproduce with the given steps.
We could not detect a problem on the Text editor side using 3.1 RC1. We tried the described scenrio by deleting/replacing inside and outside of Eclipse using Linux and WindowsXP. As mentioned by Tom the attached code could not be used. We will look at this after 3.1 again once more details are available.
Get rid of deprecated state.
.
