Bug 247573

Summary:	[api] IClassifierConstants.TYPE_LINK == "link" is not in sync with actual usage of "symbolic link" in the code
Product:	[Tools] Target Management	Reporter:	Martin Oberhuber <mober.at+eclipse>
Component:	RSE	Assignee:	David McKnight <dmcknigh>
Status:	RESOLVED FIXED	QA Contact:	Martin Oberhuber <mober.at+eclipse>
Severity:	enhancement
Priority:	P3	Keywords:	api
Version:	3.0
Target Milestone:	3.1 M4
Hardware:	All
OS:	All
Whiteboard:
Bug Depends on:	141823
Bug Blocks:

Description Martin Oberhuber

2008-09-16 17:27:24 EDT

From bug 141823 comment 2: RSE uses the String "symbolic link" everywhere in the code as classification String for symbolic link. But IClassifierConstants.TYPE_LINK is specified as the String "link".

This is not consistent. Either TYPE_LINK denotes something different than symbolic links, then we should add a constant TYPE_SYMBOLIC_LINK to the API and reference it everywhere; 

or, we specify TYPE_LINK to denote any kind of link whereas TYPE_SYMBOLIC_LINK is for symbolic links specifically; then clients such as RemoteFile and RSEFileStore should use a Regex pattern like "[a-z ]*link" in order to identify files classified as "any kind of link".

In either case, intended usage of TYPE_LINK should be documented.

Comment 1 Martin Oberhuber

2008-09-16 17:30:11 EDT

Dave what do you think about this?

Comment 2 David McKnight

2008-11-17 14:50:44 EST

(In reply to comment #1)
> Dave what do you think about this?
> 

Right now I don't know of anything that references IClassifierConstants.TYPE_LINK.  I suspect that this was intended for symbolic links since, at least for dstore, there is a classification for "symbolic link" but not for "link".  I think at one point (pre-open source) the type we used to denote a "symbolic link" was just "link".  I'm thinking of adding TYPE_SYMBOLIC_LINK and deprecating TYPE_LINK.

Comment 3 Martin Oberhuber

2008-11-17 14:59:22 EST

Sounds good to me.

Comment 4 David McKnight

2008-11-17 18:49:38 EST

I've committed the change to cvs.