[platform-core-dev] org.eclipse.core.runtime.Path issue with colons

[Ed Warnicke <eaw@xxxxxxxxx>]

I've been using CDT on an existing code base, and have discovered that it
seems to have issues with colons in filenames.  I filed a bug with 
regard to this
against CDT here:

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

I have since traced the issue down to issues in 
org.eclipse.core.runtime.Path.

It seems that there are significant 'Windowisms' in 
org.eclipse.core.runtime.Path
which render the characters ':' and '\\' both invalid characters in Path 
Segments
(and thus filenames).  Both characters are perfectly legal characters in 
Path Segments
(and filenames) under Unix/Linux (where I'm working).  The result is 
that I simply
can't create projects.

I'm going to try to make changes (and submit a patch) to fix these problems.
What I would like to do is see to it that whatever behavior the original 
author
was seeking under Windows still occurs, but that users on Unix/Linux 
systems
are not unnecessarily hamstrung.

In relation to this effort I have a few questions:
1)   What is the correct way to detect differences in the platform being run
     on so that I can intelligently apply or not apply this behavior 
appropriately?
2)   Can anyone give me any guidance on what the original author of
     this code was trying to acheive?  Some quick research indicated 
that the
     quirks in legal filenames under Windows are much more numerous than
     having ':' and '\\' be illegal characters for Path Segments, so 
I'm confused as
     to why non-Windows systems were broken here for an incomplete 
solution.

Ed

P.S. Specifically these are the places where there seem to be issues:

1)   Path.isValidSegment() returns false if it finds '/','\\'. or ':' in 
a segment.  This causes
     valid patch segments on Unix/Linux containing ':' or '\\' to be 
rejected.
2)   Path.initialize() splits on ':' and effectively discards all 
characters leading the colon
     (rolling them into the device attribute).  As a result a filename 
like
     foo:bar.c would become resource bar.c... not the correct behavior.
3)   Path.append() similarly seems to treat ':' (in the form of 
IPath.DEVICE_SEPARATOR)
     as a path seperator, which could cause all no end of mischeif in 
the many, many
     other methods calling Path.append()