Jump to: navigation, search

Difference between revisions of "PTP/designs/remote/EFS"

< PTP‎ | designs‎ | remote
(New page: = EFS Notes and Designs = List of Authors: Chris Recoskie (recoskie@ca.ibm.com) Greg Watson (grw@us.ibm.com) == EFS Problems == # IPath <==> URI conversions are not always prope...)
 
Line 29: Line 29:
  
 
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.
 
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.
 

Revision as of 12:59, 10 October 2007

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.