Community
Participate
Working Groups
Build Identifier: CDT 6.0 Hi, Eclipse CDT project has its ProjectName/src folder as specified in the Project Properties -> Paths & Symbols -> Source Location. Now suppose, the user loses its permissions or erroneously the project directory access permissions gets modified to 000 , then this directory becomes inaccessible as it should be. And in the Project Explorer, src and other folders are no more shown. Now in Project Properties -> Paths & Symbols -> Source Location , the source folders list has only ProjectName. src folder doesn't exist any more. So, now to correct the problem I change the permission of the project again to 700 recursively. And all the folders are again visible in Project Explorer but the Project Properties -> Paths & Symbols -> Source Location still shows only ProjectName/ in the folders list.. The src directory doesn't get restored. I am not very sure in which all cases the CDT uses the list of src folders from this Project Properties -> Paths & Symbols -> Source Location settings. Does it uses for indexing, scanner discovery and content assist ? We had faced problem at times with indexing though not always. If it gets used for indexing then it is a very major issue for us. Moreover, apart from this chmod access, the similar problem happens if the project workspace is in shared file system and user's authority to access the workspace gets lost. In such cases when he regains the authority, the Project Properties -> Paths & Symbols -> Source Location is still not updated and which results in problems for indexing at times. We would like to here the possible resolution for this problem. I have tried the same thing in JDT but it seems in case of JDT even when permissions are removed, the Source Folder list doesn't get changed, so the problem doesn't happens. Reproducible: Always Steps to Reproduce: 1. Create a CDT Project "C/C++ Hello World Project" 2. Build it, use indexer, check Project Properties -> Paths & Symbols -> Source Location. It shows ProjectName/src as the folder in the Source Folder List. 3. Now go to command line. execute chmod -R 000 ProjectName. 4. Once the workspace refreshes, it shows various workspace refresh errors. Along with that if you look at Project Properties -> Paths & Symbols -> Source Location. It will now show only ProjectName. 5. So, go to commandline. execute chmod -R 700 ProjectName. 6. Once again when workspace refreshes, now it shows all the folders in the Project Explorer. Now look at Project Properties -> Paths & Symbols -> Source Location. It still shows ProjectName only. rather than restoring it to ProjectName/src. 7. If you add the src folder manually, then on repeating steps from #3 onwards, it still shows the same issues.
Wanted to updated one more information in this :- We have provided our own plugin extended over CDT which creates a new project of nature C/C++ but with our tool chain and customized to our build environment. In this plugin we have some code which runs indexer and fails if the src folder is missing in "Project Properties -> Paths & Symbols -> Source Location" listing. Probably because indexer appears to fail when a .C file in a non-source folder is an input. And this error of indexing is appearing every time when indexer runs and src folder is not listed in Source Location tab. Because of this most of our source files are not indexed and various functionalities stop working.. It is a critical issue for us and would like to know the possibility of its resolution.
As you've got a plugin using this functionality, can you not write a test for org.eclipse.cdt.core.tests and propose a fix for the issue?
I am currently unable to contribute code but am willing to help. I can 1) provide a simple set of steps that re-create the problem using a Basic C++ Project setup. (2) and would try to provide some information on where the problem is happening. I will post in a separate note the exact sequence of steps that leads to the issue, in case that would help in the creation of a new testcase for it. (In reply to comment #2) > As you've got a plugin using this functionality, can you not write a test for > org.eclipse.cdt.core.tests and propose a fix for the issue?
