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).

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.

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.