Bug 181460 - [efs] EFS project fails to open on workbench startup
Summary: [efs] EFS project fails to open on workbench startup
Status: ASSIGNED
Alias: None
Product: Target Management
Classification: Tools
Component: RSE (show other bugs)
Version: 2.0   Edit
Hardware: PC Windows XP
: P3 normal with 3 votes (vote)
Target Milestone: Future   Edit
Assignee: dsdp.tm.rse-inbox CLA
QA Contact: Martin Oberhuber CLA
URL:
Whiteboard:
Keywords:
Depends on: 182363 190231 181998 182006 215820
Blocks: 170916 251863 256295
  Show dependency tree
 
Reported: 2007-04-06 15:53 EDT by Martin Oberhuber CLA
Modified: 2012-11-19 04:57 EST (History)
9 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Martin Oberhuber CLA 2007-04-06 15:53:30 EDT
+++ This bug was initially created as a clone of Bug #180091 +++

When starting a workbench which had a project created using EFS, I notice that the project fails to open. I need to switch to the RSE perspective, then manually open the project each time I re-start Eclipse.

The reason for this might be returning a NullFileSystem; or the WorkbenchUI not being ready at the time the project is needed. Perhaps it is necessary for WorkbenchUI to get ready before trying to connect to the remote side, since the ConnectorService requires a shell. For details, see bug 180091.
Comment 1 Martin Oberhuber CLA 2007-04-11 15:15:16 EDT
Investigation shows that Eclipse Platform Resources try to open remote projects too early in the startup phase, such that the EFS provider has no chance being properly initialized at the time it were necessary. This is tracked by the following bugs raised against Platform Resources:

Bug 181998 - ResourcesPlugin does too much in its start() method
Bug 182006 - Improper exception handling with IFileStore#fetchInfo()

Unless at least one of these bugs is fixed, the RSE EFS provider has no chance of re-opening remote projects on Workbench startup.

Preferred workaround is to create any projects local instead, and use Folders as linked resources, linked to the remote EFS projects. This works fine and is also described in the TM 2.0M6 build notes as well as the TM 2.0 Known Issues and Workarounds page.
Comment 2 Martin Oberhuber CLA 2007-05-10 04:30:06 EDT
I can't see how we could get rid of the dependency to org.eclipse.core.resources for TM 2.0 - deferring to a future release.

The workaround for now is to create local projects only, then add linked folders to remote resources:
  New > Folder > Advanced > Link to folder in file system > deselect default >
  Select filesystem "RSE" > Browse to remote location
Comment 3 Xuan Chen CLA 2007-09-14 10:09:08 EDT
Some other behaviour related to this problem.

If I create an RemoteProject, then open a file inside it in the editor.
Then I close Eclipse and start it again.  I got message "Resource 'Logs/Adminlog1.log' does not exist." message inside the editor.  If I open the remote project again, it has a plus sign beside it.  But there is still no contents for this project.  I need to refresh to see the contents.
I double click on the file again, there is still no update on the editor contents.  I need to close the editor, then double click on the file to bring it up properly.
Comment 4 Martin Oberhuber CLA 2007-09-14 10:18:43 EDT
(In reply to comment #3)
Yes I know... it's all because the Resources plugin needs EFS very very early in the startup sequence, and RSE can not be properly initialized at that time. This will be very tricky to fix and improved UI/Non-UI separation in RSE is a necessary prerequisite for a fix.
Comment 5 Martin Oberhuber CLA 2008-02-12 14:57:44 EST
With bug 215820 resolved, it looks like bug 190231 is the only roadblock to supporting an UI-less EFS provider.

The remaining problem during early startup is then the dependency of rse.core into org.eclipse.core.resources, induced by the PFWorkspaceAnchor which is autostart by default for the persistence provider.

There are other places, too, where rse.core depends on core.resources, but these seem to get relevant only later after startup. Resolving bug 182363 should allow us to get rid of all core.resources related code from rse.core.