RE: [platform-core-dev] Valid characters in Eclipse paths

[John Arthorne <John_Arthorne@xxxxxxxxxx>]

Colons are indeed valid characters in
Unix paths. It is true that colon is used to separate paths in some contexts
on Unix, such as the PATH environment variable, and for this reason colons
in at least directory names is not recommended (this is mentioned in the
Unix IEEE standard referenced in my proposal). However, the fact remains
that we have users requesting the ability to have colons and backslashes
in file/directory names, which is the whole reason for this proposal.

Dorian Birsan/Toronto/IBM@IBMCA
Sent by: platform-core-dev-admin@xxxxxxxxxxx

10/05/2004 04:01 PM

Please respond to
platform-core-dev

To	platform-core-dev@xxxxxxxxxxx
cc
Subject	RE: [platform-core-dev] Valid characters in Eclipse paths

John, I may be wrong, but I thought colons were invalid file path characters
on unix, so c:/foo would be invalid (it will likely mean two paths "c"
and "/foo" , as opposed to path fragments.)

-Dorian

John Arthorne/Ottawa/IBM@IBMCA
Sent by: platform-core-dev-admin@xxxxxxxxxxx

10/05/2004 02:16 PM

Please respond to
platform-core-dev

To	platform-core-dev@xxxxxxxxxxx
cc
Subject	RE: [platform-core-dev] Valid characters in Eclipse paths

As Michael has argued, 2) is not sufficient.  The path "c:/foo"
on Windows is an absolute path with device "c:" and first segment
"foo". On Unix it is a relative path whose first segment is "c:"
and second segment is "foo". This ambiguity can only be solved
with a platform-specific factory method that recognizes the device separator
on platforms that have a device. Using the two argument path constructor
to solve this particular case doesn't help, since it shifts responsibility
for platform-specific handling onto the caller (they must call the two
parameter constructor on Unix, and the one argument constructor on Windows).

3) All platforms that I know of collapse multiple connected front slashes,
with the exception of the leading double-slash for UNC paths. I don't think
anyone is asking for multiple front slashes in segments, since this has
no meaning on any platform targeted by Eclipse.  Removing the '\'
restriction is easy given that we need platform-specific behaviour to solve
the colon problem. If we're going to make this change, we might as well
lift all restrictions that prevent valid names from being used on Unix.

The biggest problem with my original proposal is that it doesn't preserve
compatibility of the IPath.toString implementation between 3.0 and 3.1.
 This is too likely to cause breakage, so I am currently writing up
a counter-proposal that preserves toString() compatibility. Stay tuned.
Thanks for all the feedback so far.

"Ed Burnette" <Ed.Burnette@xxxxxxx>
Sent by: platform-core-dev-admin@xxxxxxxxxxx

10/05/2004 11:41 AM

Please respond to
platform-core-dev

To	<platform-core-dev@xxxxxxxxxxx>
cc
Subject	RE: [platform-core-dev] Valid characters in Eclipse paths

The proposal, while well reasoned, seems like a lot of change to solve
a simple problem. I looked at all the bugzilla entries and most people
just wanted colons in filenames; a few wanted leading/trailing spaces,
and one or two wanted slashes. Here's an alternative to consider:
 
1. Spaces are easy, just allow them anywhere. 
 
2. Colons are easy too. In Path(fullPath), make everything before the first
colon the device and leave any other colons untouched. In Path(device,path),
do not scan path for colons at all. Note that's not an API break, just
an implementation detail. Currently these two constructors go to the same
initialize() function but there's no reason it has to be that way.
 
3. For slashes, paths that start with two slashes (of either kind) are
UNC paths; otherwise multiple slashes are left alone. In either constructor
either a forward slash or a backward slash is considered a directory delimiter.
Slashes in segment or file names are just not supported.
 
I don't think continuing to disallow slashes poses any great hardship if
the other restrictions are lifted. And it requires no API changes other
than a slight relaxing of isValidSegment() and isValidPath().
 
This alternative also preserves the property of Paths that you can take
a Path, turn it into a string, turn it back into a Path, and it would equal
the first Path. If you start allowing slashes then the intermediate string
is ambiguous. 
 
Finally, it is convenient to be able to construct a path using rules that
we're used to. In particular the path constructor should handle these forms
without requiring extra slashes: 
 
  c:/folder/file.txt or c:\folder\file.txt 
  //server/volume or \\server\volume
 
If we want lots of extra slashes we can use the URL constructors :).
 
What do you think?

---

From: platform-core-dev-admin@xxxxxxxxxxx
[mailto:platform-core-dev-admin@xxxxxxxxxxx] On Behalf Of John Arthorne
Sent: Monday, October 04, 2004 3:30 PM
To: eclipse-dev@xxxxxxxxxxx; platform-core-dev@xxxxxxxxxxx
Subject: [platform-core-dev] Valid characters in Eclipse paths


The org.eclipse.core.runtime.IPath data structure in Eclipse currently
imposes restrictions on what characters and segments it allows. This prevents
files with certain names from being added to an Eclipse workspace (most
notably files and directories that contains the colon ':' and back slash
'\' characters.  The following document proposes a solution to this
problem in Eclipse 3.1.  Plugins that create or use paths are encouraged
to read this proposal and provide comments to the platform-core-dev mailing
list.  To reduce noise, please do not reply to the eclipse-dev mailing
list. 

http://dev.eclipse.org/viewcvs/index.cgi/%7Echeckout%7E/platform-core-home/documents/path_changes.html
--