Bug 151089 [EFS] Closed projects on remote filesystem cause unwanted connection attempts
When a project is located on a remote filesystem (e.g. a WebDAV server) and this project is closed when starting Eclipse, Eclipse will cause cconnection attempts to that remote system. This is especially undesirable if those projects were closed because the remote system was shut down in the first place. The following is a stacktrace of Eclipse's first attempt to reach a remote system at startup, followed by some clarification. 8 WebDAVFileSystem.getStore(URI) line: 49 7 InternalFileSystemCore.getStore(URI) line: 107 6 EFS.getStore(URI) line: 296 5 FileStoreRoot.toLocalPath(URI) line: 120 4 FileStoreRoot.<init>(URI, IPath) line: 57 3 FileSystemResourceManager.setLocation(IResource, ResourceInfo, URI) line: 806 2 Project.internalSetDescription(IProjectDescription, boolean) line: 663 1 SaveManager.restoreMetaInfo(Project, IProgressMonitor) line: 782 SaveManager.restoreMetaInfo(MultiStatus, IProgressMonitor) line: 746 SaveManager.restore(IProgressMonitor) line: 637 SaveManager.startup(IProgressMonitor) line: 1299 Workspace.startup(IProgressMonitor) line: 1883 Workspace.open(IProgressMonitor) line: 1653 ResourcesPlugin.startup() line: 367 ... 1 SaveManager.restoreMetaInfo(Project, IProgressMonitor) line: 782 A project description is tried to be read; if the project is closed, it cannot be read and a dummy IProjectDescription is created. This description is then set with an internal method (the API method setDescription can only be used on existing open projects). 2 Project.internalSetDescription(IProjectDescription, boolean) line: 663 For some reason Eclipse interprets a closed project as being a resource that has its location changed and so it is set again (to a WebDAV location: webdav://). 3 FileSystemResourceManager.setLocation(IResource, ResourceInfo, URI) line: 806 To set the location, a new FileStoreRoot is created with root URI the URI of the remote project location (webdav://). 4 FileStoreRoot.<init>(URI, IPath) line: 57 The FileStoreRoot constructor tries to find out the local file that corresponds with the given WebDAV URI. If this is not possible, null will be stored (eventually this will happen, but only after the nonreachable remote system has been tried to be contacted). 5 FileStoreRoot.toLocalPath(URI) line: 120 The filesystem corresponding to the URI scheme (webdav) is requested with EFS. 6 EFS.getStore(URI) line: 296 An IFileStore is requested for the given WebDAV URI. 7 InternalFileSystemCore.getStore(URI) line: 107 The IFileSystem corresponding with the scheme of the given URI (webdav) is retrieved (WebDAVFileSystem). This filesystem is asked for an IFileStore representing the given URI. 8 WebDAVFileSystem.getStore(URI) line: 49 An attempt is made to create a WebDAVFileStore that represents the given URI. If it is not possible to create a file store corresponding to the provided URI, a file store belonging to the null file system should be returned. However, in order to know whether it is possible to create a file store, the WebDAV server should be contacted to determine if it responds. In my opinion, step 3 is the strangest: why must a closed project have its location set?
bundles/org.eclipse.ui.ide/src/org/eclipse/ui/internal/ide/dialogs/IDEResourceInfoUtils.java
}
	/**
	 * Get the file store for the URI.
	 * @param uri
	 * @return IFileStore or <code>null</code> if there is a
	 * {@link CoreException}.
	 */
	public static IFileStore getFileStore(URI uri) {
		try {
			return EFS.getStore(uri);
		} catch (CoreException e) {
			log(e);
			return null;
		}
	}
	private static void log(CoreException e) {
		IDEWorkbenchPlugin.log(e.getMessage(), e.getStatus());
	}
	/**
	 * Return the file stores that are a child of store that the filter 
	 * accepts.
	 * @param store
	 * @param fileFilter
	 * @param monitor
	 * @return IFileStore[]
	 */
	public static IFileStore[] listFileStores(IFileStore store, IFileStoreFilter fileFilter, IProgressMonitor monitor) {
		ArrayList result = new ArrayList();
		IFileStore[] children;
		try {