[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [platform-core-dev] Valid characters in Eclipse paths
|
On Linux:
hagbard@eaw-linux:~$ uname -a
Linux eaw-linux 2.6.6-1-686 #1 Wed May 12 14:57:57 EST 2004 i686 GNU/Linux
hagbard@eaw-linux:~$ mkdir c:
hagbard@eaw-linux:~$ touch c:/foo
hagbard@eaw-linux:~$ ls c:
foo
On Solaris:
SunOS minli-u5 5.6 Generic_105181-28 sun4u sparc SUNW,Ultra-5_10
eaw-u5:2> mkdir c:
eaw-u5:3> touch c:/foo
eaw-u5:4> ls c:
foo
Alas I don't have access to AIX, HPUX, or other posix flavored OS's...
Similar experiments can be done to show that the '\\' and leading and
trailing
whitespace limitations are likewise inappropriate for posixish systems (aka
everything but Windows).
Ed
Dorian Birsan wrote:
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_ <file://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
--