Revision as of 14:21, 11 October 2007

EFS Notes and Designs

List of Authors:

   Chris Recoskie (recoskie@ca.ibm.com)
   Greg Watson (grw@us.ibm.com)

Overview

Eclipse Filesystem (EFS) support was added to the Eclipse Platform in version 3.2, and the conversion has been mostly completed in 3.3. However, CDT presents a much more complex and challenging environment for such a conversion process, and to date there has been no concerted effort to do so. With interest in remote development environments increasing, there is now enough momentum to attempt to transition CDT to be fully EFS compliant. The aim of this document is to provide a central resource for this conversion process.

Issues

EFS introduces some significant changes to the traditional notion of the workspace. The most important of these is that EFS abstracts away the notion that a particular physical filesystem is used to store data in the workspace. Pre-EFS, it was possible to operate directly on resources using Java classes such as java.io.File, however with EFS this relationship can no longer be assumed to work. The resource may be contained in a zip file, or may even be physically located on a different computer.

Eclipse plugins that operate entirely within the confines of the Eclipse platform can overcome this issue relatively easily: simply use the IResource interfaces, or where direct file/directory operations are required, fetch the IFileStore/IFileInfo interfaces using the resource URI. For CDT, however, a large portion of the functionality requires interaction with tools that are completely external to the Eclipse environment. Unfortunately, many of these tools are used to interact with both workspace and non-workspace resouces. This is further complicated because the workspace resources may not even exist on the local machine, but instead may be accessed from a remote system. In this case, some, or all, of the tools themselves may need to be executed remotely in order to gain access to the resources. Running tools remotely like this is beyond the scope of this document, but still needs to be taken into consideration during the EFS conversion process.

EFS Problems

1. IPath <==> URI conversions are not always properly handled

Consider the following example:

IPath path = new Path("c:", "/a/b/c"); IFileStore f = EFS.getLocalFileSystem().getStore(path); then print out f.toURI() you get something like: file:/path/to/workspace/c:/a/b/c

1. Lack of Windows path support

• There is no device field in a URI. I.e., it's not legal to have c: in a URI.
• There is no notion of root on windows

  How do you distinguish between the following?
  ** the full path C:\a which becomes file://c/a
  ** the relative path c/a which then also becomes file://c/a

  It might be possible to handle this by forcing the latter to be file://./c/a but neither URI nor EFS enforces anything like this.

1. URIs lose OS specific information.

Since a URI is just a string, it doesn't really store information about where it came from. For example, say you have the URI file://a/b. Is that a UNIX-style path corresponding to /a/b, or was it a Windows path corresponding to a:\b? You just don't know.