[
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
|
Jeff... no apology needed on the recap. This started because I was
having issues
trying to create a CDT project over a large existing code base. I got
an error
(quoting from my bug 72718):
"Errors occurred while refreshing resources with the local file system.
ftpsrvcmd.ysrc.a9b4e487.3e7f11d1.b933.00:01:80:81:dd:5c is an invalid
resource
name."
which precluded the creation of the project. So I went looking for the
string
"is an invalid resource name"
in org.eclipse.core.resources and found it in
/org.eclipse.core.resources/src/org/eclipse/core/internal/utils/messages.properties
associated with
"resources.invalidResourceName"
seaching for that took me to
/org.eclipse.core.resources/src/org/eclipse/core/internal/localstore/RefreshLocalVisitor.java
where it was referenced in:
if (node.existsInFileSystem() &&
!Path.EMPTY.isValidSegment(node.getLocalName())) {
String message =
Policy.bind("resources.invalidResourceName", node.getLocalName());
//$NON-NLS-1$
errors.merge(new
ResourceStatus(IResourceStatus.INVALID_RESOURCE_NAME, message));
return false;
}
So looking in Path.isValidSegment() I noticed that names containing ':'
didn't qualify as valid. So I
figured that was my problem :)
All I really want to do is to be able to get my project created :)
I absolutely understand wanting IPath to represent what you want in your
resource
tree, and your case sensitivity example is a good illustration of that.
I can
get behind that. The problem is where as case sensitivity does not
render valid
filename choices in Windows invalid, the ':' and other related restrictions
DO render valid filenames in POSIX land invalid, thus rendering whole
code trees
(like mine) incompatible with Eclipse.
By making IPath case-sensitive you have effectively underconstrained it on
Windows. There are things it can express (file name collisions like
FooClass.java and Fooclass.java) that are invalid on Windows. By excluding
':', '\\' and leading and trailing whitespace from Path Segments you have
overconstrained IPath on POSIX compliant systems.
The distinction is this: Someone importing an existing Windows
project will not have a tree rejected as invalid, because your
constraints are looser than that of the OS. Someone importing an
existing project on a POSIX compliant system may have their tree
rejected because you're constraints are stronger than that of
POSIX. Someone looking to share a project between Windows and
a POSIX complaint system has exactly the same issues whether they
are using Eclipse or not. So you've made the situation worse on POSIX,
unchanged on Windows, and unchanged for cross platform work.
All I'm seeking is that you not overconstrain on POSIX compliant systems.
So here is my basic problem, I need to be able to handle filenames
that contain ':' (and probably while we're solving that one we should
look at allowing filenames containing '\\' and leading and trailing
whitespace) if the underlying OS will allow them. Any suggestions on
how to get that accomplished cleanly? I'm really not terribly
particular about HOW we solve this problem, but it really
does need to be resolved, and a lot sooner than another 2 years.
Ed
Jeff McAffer wrote:
I just tuned into this thread and so apologize if I recap...
Where exactly are IPath and Path causing you problems? They are meant
mostly as a utility class for people wanting to manipulate '/'
separated strings (with an optional X: drive annotation). They are
NOT meant as a replacement for java.io.File (as much as one might want
a replacement). We were probably overzealous when including drive
letter annotations but they are optional so one can use IPath/Path
quite happily without ever spec'ing a drive letter. People wanting to
manipulate filesystem paths would be well-advised to use java.io.File
wherever possible.
There are relatively few places where the runtime exposes IPaths with
any consequence. Is it one of these API? If so, which one(s)?
The Resources plugin uses IPath and Path extensively to define and
manage its tree structure. Here the issues of case sensitivity and
excluded chars becomes very relevant (note that drive letters are not
relevant here). The resource tree is not case sensitive because IPath
is, IPath is case-sensitive because we wanted a case-sensitive tree,
etc etc. That is, the path behaviour follows the behaviour we wanted
for the resource tree not the other way around.
Why did we want such lowest common denominator behaviour for the tree?
The resource tree has to handle resources that come from many
different sources. You might work on Windows, me on Linux, the next
guy on Mac. We all stash our resources in CVS (running on some OS).
Then I check out yours, you mine, ... It was found through bitter
experience that people get quite grumpy when you munge their resource
structures because, for example, a particular char is special on one
file system and not on another. Similarly for case-senstivity.
Imagine checking in some duplicate but mixed case names on Linux only
to find that Windows users get only one resource!
As for changing API, it is not really about the API as such but more
in the current uses of the behaviour (specified or otherwise). By
asking, for example, to have IPath change its sensitivity depending on
the local file system, you would be asking for the resource tree to
become insensitive on Windows but sensitive on Linux. This would
cause massive problems with existing resource structures. Similarly
for changes in how path strings are interpreted (special chars etc).
Neither John nor I would want to "shut you down" but it would be
remiss of us to not point out the issues and challenges. I for one
would happily donate all my +1 powers to anyone who can come up with a
solution which is notably better and can be integrated in a consistent
way so as to not put off vast numbers of existing plugin writers or
Eclipse users.
Jeff
*Ed Warnicke <eaw@xxxxxxxxx>*
Sent by: platform-core-dev-admin@xxxxxxxxxxx
08/31/2004 06:54 PM
Please respond to
platform-core-dev
To
platform-core-dev@xxxxxxxxxxx
cc
Subject
Re: [platform-core-dev] org.eclipse.core.runtime.Path issue with colons
I understand taking API contract compatibility seriously, however I
wouldn't characterize
this as a flaw, I'd characterize it as a BUG. My basic tendency would
be to fix the bug, correct
issues in the Eclipse code base that arise from fixing the bug,
publicize the fix so third
parties can fix their issues and move on. What sort of issues do you
forsee arising from the
proposed contract change other than intolerance of path separator
literals?
Ed
John Arthorne wrote:
>
> That is a fairly accurate summary of the situation. If I were writing
> a gripe list about IPath, I would also add the fact that it is always
> case-sensitive, regardless of the underlying file system. This causes
> problems on platforms such as Windows, for example. Despite these
> problems, API contract compatibility is taken very seriously in the
> Eclipse platform, even when that API has flaws.
>
> Ed Warnicke wrote on 08/31/2004 05:45:23 PM:
>
> > OK, let me see if I understand correctly:
> >
> > 1) IPath provides segmented paths, for this purpose we
> > need a path separator character.
> > 2) We disqualify from path segments all characters that
> > are used as path separators on known platforms
> > ('/' and '\\') whether they are path seperators on the
> > running platform or not so that in the event that
> > someone incorrectly hard codes a literal (as opposed
> > to using System.getProperty("path.separator")).
> > 3) In order to support the drive letter feature on Windows
> > (and I've still seen no other rationale) we need a
> > driver separator character (hard coded as ':'). We therefore
> > disqualify the character ':' whether the platform we are on
> > has driver letters or not.
> > 4) This causes breakage because it invalidates path segments
> > that are perfectly valid on POSIXs compliant platforms
> > (pretty much everything but Windows).
> > 5) Because this behavior is part of a published interface we
> > are not going to fix it.
> >
> > Is this an accurate summary of the situation?
> >
> > This problem has been open for almost 2 years now... it's only
going to
> > get more painful to fix going forward. I'm willing to do the work to
> > fix it,
> > but not if I'm just going to be shutdown for trying to change a
> 'published
> > interface' even if that interface is broken.
>
_______________________________________________
platform-core-dev mailing list
platform-core-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/platform-core-dev
