PTP/designs/remote/EFS

EFS Notes and Designs

List of Authors:

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

EFS Problems

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

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.

New Representation of Paths

We have concluded that due to the above problems we need some kind of new representation for paths. In order to provide interoperability with EFS this new representation will have to be able to convert to a valid URI, but this should only be done when interacting directly with EFS itself, otherwise information may be lost.

Requirements:

• Track the OS the original path was created for, and be able to extract the original path.
• Convert the path to another OS
• Convert the path to be relative to another machine (most likely with a different root directory and potentially on a different OS).
• Distinguish between local, remote, and local-relative-to-remote paths.
• Provides a toURI() method
• Provides utility functions for path manipulation (append, get at segment, get the file extension, etc.) similar to what is contained in IPath.