[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [platform-core-dev] org.eclipse.core.runtime.Path issue with colons
|
John,
Could you give me an example in Eclipse where IPath's device field is
being used for something other than a windows drive letter?
Ed
John Arthorne wrote:
I was not the initial author, but I will try to explain the design
rationale of IPath. This is an abstract data structure consisting of a
device and a series of segments. While it is largely used to represent
file system paths, it can also represent network paths, or other
abstract paths in non file-system trees. To support these
requirements, it needed to reserve two characters: one for the device
separator, and one for the segment separator. Thus / and : are
reserved, independent of the operating system used (similarly, Unix
reserves / and null characters). Since Eclipse uses IPath as a lookup
mechanism for the in-memory representation of the workspace, these two
limitations carry forward into Eclipse. Again, these limitations were
not introduced with any particular operating system in mind. The
Eclipse workspace (just one client of the abstract IPath data
structure) imposes further checking on resource paths depending on the
operating system, invalidating characters and strings that are not
allowed under that system.
We are aware of these limitations on *nix platforms (worse on Mac
which also allows '/' in filenames). While a solution would be
welcome, it is not as easy as changing the semantics of IPath based on
the underlying operating system, as this would break other clients of
the data structure. Also, the treatment of \ and / as equivalent is
not easy to change, since existing code may be using \ in path names
and expecting the conversion to happen for free.
Here is the bug report reference, if you want to CC yourself or add
further comments:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=24152
--
*Ed Warnicke <eaw@xxxxxxxxx>*
Sent by: platform-core-dev-admin@xxxxxxxxxxx
08/27/2004 07:09 PM
Please respond to
platform-core-dev
To
platform-core-dev@xxxxxxxxxxx
cc
Subject
[platform-core-dev] org.eclipse.core.runtime.Path issue with colons
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()
_______________________________________________
platform-core-dev mailing list
platform-core-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/platform-core-dev