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

[Michael Valenta <Michael_Valenta@xxxxxxxxxx>]

Sorry. Perhaps I was unclear. My point
was that the CVS plugin does not want the colon to be a device separator
at all. Ed proposed to make everything before the first colon the device
when using the Path(String) constructor. For CVS, we would want a constructor
(or factory method) that treated the String as a relative path (i.e., no
device) even if there were colons so that files that contained a colon
in the filename could be handled properly.

Michael

Ed Warnicke <eaw@xxxxxxxxx>
Sent by: platform-core-dev-admin@xxxxxxxxxxx

05/10/2004 01:28 PM

Please respond to
platform-core-dev

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

Question, if the CVS plugin uses the colon as a device
seperator, what 
happens under this
new proposal if I attempt to check out a file from a cvs repository that
contains a colon
in the filename?

Ed
Michael Valenta wrote:

>
> 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
> > -- 


_______________________________________________
platform-core-dev mailing list
platform-core-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/platform-core-dev