Community
Participate
Working Groups
Created attachment 215285 [details] Sample EFS provider plugin I am using EFS as part of a very popular resource management system. Some of my customers are using it in conjunction with both JDT and CDT. Eclipse EFS allows filesystem providers to create virtual hierarchies for projects from a variety of sources (e.g. Zip, Http): http://wiki.eclipse.org/index.php/EFS When using CDT in conjunction with a project that is managed by a non-local filesystem provider it falls over trying to populate the virtual folders for the includes. Also, when it invokes the compiler it invokes it in non-existent directories and/or provides invalid paths to the source code files. Attached to this bugzilla is a zip of a sample EFS provider (very basic) that uses its own URI scheme but has a one-to-one mapping back to files in the local filesystem. Note that the "path" of the URI cannot be used directly to go to the local filesystem because it has special segments in it. Here are the steps to reproduce the problems: 1) Compile and install the provided plugin (or just use a runtime-workbench) 2) Create both a CDT and JDT projects with some sample content 3) Delete the CDT project (do not delete contents on disk) 4) Right click on the JDT project->Load Project 5) Pick the directory on the local filesystem where the CDT project resides 6) Delete the JDT project (do not delete contents on disk) 7) Right-click on the CDT project->Load Project 8) Pick the directory on the local filesystem where the JDT project resides Right-click on each project and show properties. Notice that in the "Location:" field they have special "foo" URI's and not the default path locations. They are now managed by the special EFS provider. In the JDT project, you can navigate, make changes and build the project without any problems. However, in the CDT project, the "includes" folder is missing and whenever I build it there are compiler errors due to missing paths: Internal Builder: Cannot run program "g++" (in directory "foo\C:\Users\cbmcgee\Downloads\eclipse-cpp-indigo-SR2-incubation-win32-x86_64(1)\eclipse\runtime-New_configuration\aproject\Debug"): CreateProcess error=267, The directory name is invalid. CDT should not be assuming that it can directly use the path portion of the URI directly. Instead, it should probably use something like IResource.getRawLocation().toFile() to get the file on the local file system.
EFSExtension is probably what you want to investigate. We created this this extension point to handle exactly this scenario.
Created attachment 219480 [details] patch-v01 I noticed that UNCPathConverter.toPath is not giving EFS a chance to resolve a path with a custom protocol. This patch attempts to fix this issue. I run autotools test cases, and the patch doesn't seem to break anything. I also tested that the scenario with a CDT project under Jazz source control. Navigating the project through "Open declaration" works with the patch.
Created attachment 219526 [details] pacth-v02 In the previous patch egit included some meaningless classpath changes. Corrected now.
Dough, Chris - is the patch OK? Will you push the patch to head and 8.1.1?
Can you push this change request to Gerrit. Instructions are here: http://wiki.eclipse.org/index.php/CDT/git. It's much easier to review and get submitted that way.
(In reply to comment #5) > Can you push this change request to Gerrit. Instructions are here: > http://wiki.eclipse.org/index.php/CDT/git. It's much easier to review and > get submitted that way. Hi Doug, Here is the change in Gerrit: https://git.eclipse.org/r/#/c/7184/ Will you review it, please?
Chris, Doug, Did you have a chance to look into the fix?
I approved the change in Gerritt, it has been merged to master.
Thanks Chris very much. Will it be also available in CDT 8.1.1?
You had only submitted the patch in Gerritt against master, so that is the only place it was applied. Applied to cdt_8_1 as well.
Thanks Chris :)
Created attachment 258769 [details] An update of the Sample EFS provider plug-in Just to have it available - I've attached an update to the Sample EFS Provider Plug-in. It is a binary bundle and you can drop it into your environment to run.
Re-opening as this is still an issue in Eclipse 4.4.2 with CDT 8.6. The steps in the original description still apply and the test bundle in comment 12 can be used for testing.
(In reply to DJ Houghton from comment #13) > Re-opening as this is still an issue in Eclipse 4.4.2 with CDT 8.6. Have you tested with CDT 8.8?
Surya will try CDT 8.8 today and post his results here.
I tried with Eclipse Mars and CD 8.8. I still see the issue. The .cpp automatically added this line - #include "foo/C:/Download/RTCClient/502/Testing2/CDT_Project/Hello2.h" Which is not correct.
The sample EFS provider has been posted to a github project with source code and update site: https://github.com/sirnewton01/eclipse-filesystem-example
It's never going to work unless you have an EFSExtension to go with your filesystem. This should be closed in my opinion. The extension point is there for those with weird custom filesystems to provide support for them.
This is an urgent issue for one of our customers. I am not an Eclipse expert, but the following has been suggested: As part of its attempt to get a pathname, CDT is looking inside a URL to get a pathname, which happens to work in some cases, but which isn't part of the API. There is an Eclipse API that is defined to return the pathname (IResource.getLocation). Would it be possible, for CDT to try the IResource.getLocation call before looking inside the URL (and use the IResource.getLocation result, if it is non-null). This would then ensure a valid pathanme for any IResource implementation that supports the IResource.getLocation call, and do no harm for those that do not.
For the above mentioned problematic files there is no "location" information since they are outside the eclipse workspace. Looking at the code the only viable and safe approach is to implement the mentioned EFSExtension point.
WRT comment 20, my understanding is that EFS resources are logically within the Eclipse workspace, and in this particular EFS provider, the resources also exist on the local file system, and so there is a local path to each of these resources. Unless their is a bug in their EFS provider (which they would fix, if that is the case), getLocation applied to these EFS resources will return the correct local path. Marko: Let's have a phone conversation, and then report back our conclusions to this thread.
This bug was assigned and targeted at a now released milestone (or Future or Next that isn't being used by CDT). As that milestone has now passed, the milestone field has been cleared. If this bug has been fixed, please set the milestone to the version it was fixed in and mark the bug as resolved.
