Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 324206

Summary: Use wildcard in browse dir; results don't remove wildcard
Product: [Tools] PTP Reporter: Beth Tibbitts <beth>
Component: RDTAssignee: Project Inbox <ptp-inbox>
Status: RESOLVED WONTFIX QA Contact:
Severity: normal    
Priority: P3 CC: g.watson
Version: 4.0.2   
Target Milestone: ---   
Hardware: PC   
OS: Mac OS X - Carbon (unsup.)   
Whiteboard:
Attachments:
Description Flags
contains modified java file none

Description Beth Tibbitts CLA 2010-09-01 10:33:29 EDT 
Create a remote C/C++ project.
In project Properties, Remote Development, Remote Paths and Symbols,
Add..    and in the Remote Include Directory Dialog, hit Browse...

In Select Directory text field, enter e.g. "/usr/local/o*"
The dialog is populated correctly with things that start with 'o'
But if you choose one and then hit OK, the Directory field shows:
/usr/local/o*/openmpi-1.4.2-intel-11.1
Which is invalid.
Comment 1 Greg Watson CLA 2010-12-15 19:10:05 EST 
is this still a problem?
Comment 2 Beth Tibbitts CLA 2011-06-20 11:21:42 EDT 
Yes this is still a problem in PTP 5.0.0
Comment 3 Ginger CLA 2011-11-01 17:02:18 EDT 
Created attachment 206293 [details]
contains modified java file

Modified: org.eclipse.ptp.remote.remotetools.core/src/org/eclipse/ptp/remote/remotetools/core/RemoteToolsFileStore.java's RemoteToolsFileStore method.

When doing a browse using a "*" in the path, the value does not get properly added to the instanceMap.  I removed the unwanted characters from the path prior to it being replaced back into the instanceMap.

I tested with a Remote C Project and a Synchronized Project on a 64-bit Linux system.
Comment 4 Greg Watson CLA 2011-11-18 14:08:30 EST 
The trouble with this approach provided by the patch is that globbing (i.e. expanding shell meta-characters like '*') is not supported by EFS. The reason it's working in this case is that the Remote Tools implementation just happens to use a shell to expand the path, but other remote providers may not, so the user would be confused as to why it would work in some cases and not others. Also, a shell uses a number of other characters for expansion (e.g. '?', '[', ']', etc.) which will not work using the supplied patch. Finally, a path such as '/usr/local/o*/openmpi-1.4.2-intel-11.1' may actually be a valid path, since there is nothing disallowing a '*' in a path (try a command like "touch 'a*'"). The patch prevents this path from working as intended.

The correct place to implement this is in the RemoteResourceBrowser, which is more analogous to a shell. The browser would need to do something like checking for the presence of shell meta-characters in the supplied path. If the were present, it would need to use the IFileStore#childStores() method to find the names of all the children in the path segment, then match the children against the supplied path using shell expansion rules. The IFileStore objects that match the path would then be displayed. Because the IFileStore objects were obtained via a supported mechanism, their paths should be correct.

The current behavior is really a bug in the Remote Tools implementation, and probably should be disabled.
Comment 5 Greg Watson CLA 2014-05-29 15:26:31 EDT 
See last comment.