Re: [cdt-dev] Remote EFS designs

[Chris Recoskie <recoskie@xxxxxxxxxx>]

This entire discussion sounds extremely familiar... it's like I've stepped out of a time machine to late 2007/early 2008 when I tried to bring this up the last time.

See https://bugs.eclipse.org/bugs/show_bug.cgi?id=207078

In short... right now we are forced to make the assumption that the path component of URI's for EFS resources contains the absolute filesystem path where the file truly resides on whatever machine the file is on.

We do path manipulation right now by taking the raw path out of the URI and shoving it into Path(String). This is fraught with problems, as people have mentioned, because IPath wants to format everything as the local filesystem, and there is no way to explicitly ask it for a path in a particular format after you've performed whatever manipulations you want to perform. Right now we resort to calling IPath.toPortableString() as then we know the path should work on UNIX systems that way, and our primary use case is Eclipse running on a Windows PC, pointing at a remote UNIX system. This makes doing say Windows->Windows 64 or anything else with a Windows backend fail miserably.

We could probably replace some of these IPath hacks with the new URIUtil.append() from equinox, but that is only just new in 3.5. It doesn't cover all the cases that IPath does though, and still suffers from the assumption that the path component of the URI is the way to do things.

In my opinion, the path manipulation facilities should lie in the EFS filesystem (or at least something tied to it and implemented by the same people that provide the filesystem), as it is the only thing that knows the ins and outs of how its URI representation works. Anything else is bound to fail at some point.

Encoding conversions tend to get handled automatically underneath the hood at the EFS filesystem layer, but I don't know if that's guaranteed that a given provider will do this, as I'm not sure they are not required to do so. I know this is how we're handling EBCDIC conversions on System z.

===========================
Chris Recoskie
Team Lead, IBM CDT and RDT
IBM Toronto
Alex Blewitt <alex.blewitt@xxxxxxxxx>

Alex Blewitt <alex.blewitt@xxxxxxxxx>
Sent by: cdt-dev-bounces@xxxxxxxxxxx

05/28/2009 06:46 PM

Please respond to
"CDT General developers list." <cdt-dev@xxxxxxxxxxx>

To	"CDT General developers list." <cdt-dev@xxxxxxxxxxx>
cc
Subject	Re: [cdt-dev] Remote EFS designs

On Thu, May 28, 2009 at 10:50 PM, Chris Genly <chgenly@xxxxxxxxx> wrote:
> I think, in pre EFS times, IPath covered the workspace and file system.  Now
> IPath covers only the workspace.  The filesystem is replaced by the EFS
> which requires URIs instead of a path.

No, this is not correct. That is what *should* happen, but Path
enforces constraints based on the local operating systems'
requirements.

http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.equinox/components/bundles/org.eclipse.equinox.common/src/org/eclipse/core/runtime/Path.java?root=RT_Project&view=markup

		 /* (Intentionally not included in javadoc)
		  * @see IPath#isValidSegment(String)
		  */
		 public boolean isValidSegment(String segment) {
		 		 int size = segment.length();
		 		 if (size == 0)
		 		 		 return false;
		 		 for (int i = 0; i < size; i++) {
		 		 		 char c = segment.charAt(i);
		 		 		 if (c == '/')
		 		 		 		 return false;
		 		 		 if (WINDOWS && (c == '\\' || c == ':'))
		 		 		 		 return false;
		 		 }
		 		 return true;
		 }

This prevents any Path being created with a \ or : in the name on
windows platforms, even when the EFS filing system has nothing to do
with windows filing systems. Ditto the / for all platforms. Basically,
it should not be up to the Path to determine if something is a valid
name or not; it should be delegated to the EFS implementation in
question.

Alex
_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-dev