Ed,
From the standpoint of how the CVS plugin uses the Path constructor,
what you propose in point 2 would not work. Even if a relative path
contains a colon, it must not be treated as a device separator. The
only way I can see to solve it is for the Path API to provide an
alternate constructor that is speced to not treat the colon as a
device separator.
Michael
platform-core-dev-admin@xxxxxxxxxxx wrote on 05/10/2004 11:41:04 AM:
> 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
notsupported.
>
> 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
> --
