Community
Participate
Working Groups
Platform/resources has some logic to cut off the resource tree if it encounters cyclic symlinks. The change from bug 311189 acts against this by doing a refreshLocal() on removed resources. If the removed resource is actually pointing at a symlink cycle, the refresh will again add that part of the tree (because of bug 251159). The result is an endlessly growing resource tree. Steps to reproduce: 1) Create empty C/C++ project on Linux 2) Create linked folder to /sys 3) Expand to a node which contains an excluded cyclic symlink (in my case /sys/bus/acpi/device:00) 4) Perform a refresh on the node (to extend the tree beyond the cycle) 5) Perform a refresh on the project The expected result of the last refresh is that the resource tree should shrink to its original size, but it grows the tree even more.
Perhaps there's a better way to fix bug 311189, as it causes other problems. CCRC, for example, deletes .copyarea.db files from the resources tree when they appear as a result of refresh. It has a hook which prevents the resource from being removed from the fs. Of course CDT detects the file is there and makes it reappear (obv. CCRC should be using another mechanism to hide the files from the resource tree...). Perhaps a solution is not to #refreshLocal so aggressively and only do so if we're about to remove settings as the result of a resource disappearing?
(In reply to comment #1) > Perhaps a solution is not to #refreshLocal so aggressively and only do so if > we're about to remove settings as the result of a resource disappearing? I don't have enough insight into the logic to tell if it would help. I actually thought about replacing the refreshLocal() by a fetchInfo() on the underlying IFileStore to see whether the resource actually exists. I am not sure if this is still sufficient for bug 311189.
(In reply to comment #2) Sounds good -- so I guess something like: if (EFS.getStore(from.getLocationURI()).fetchInfo().exists()) continue; There's a test for this, if that's green then go for it :)
(In reply to comment #3) > (In reply to comment #2) > Sounds good -- so I guess something like: > if (EFS.getStore(from.getLocationURI()).fetchInfo().exists()) > continue; Exactly. > There's a test for this, if that's green then go for it :) In fact the test fails! The reason is that srcFolder.create(true, false, null); does _not_ create the folder in the file system. For the test, a simple from.exists() is actually sufficient, but I suppose that does not reflect the real world scenario. Is it OK if I change the test to create the srcFolder in the filesystem as well, ie. srcFolder.create(true, true, null);
(In reply to comment #4) > srcFolder.create(true, true, null); Whoops, yes. That's a bug in the test.
Created attachment 197581 [details] Patch I'll schedule this for 8.0.1.
CQ:WIND00280674
Fixed in master and cd_8_0. I added also a null pointer check for the locationURI, as I saw NPEs from the JUnit tests.
It that this change that causes +55 Unit test failures on Hudson? https://hudson.eclipse.org/hudson/job/cdt-nightly/lastCompletedBuild/testReport/
That's build #743, more permanent link is https://hudson.eclipse.org/hudson/job/cdt-nightly/743/testReport/.
(In reply to comment #9) > It that this change that causes +55 Unit test failures on Hudson? > https://hudson.eclipse.org/hudson/job/cdt-nightly/lastCompletedBuild/testReport/ I doubt it very much. I cannot see how this change would trigger those failures. Nevertheless I have rerun the managedbuild.core tests and the result is the same with or without this change (5 failures). Looking at the test results of build 741, it seems only half of all tests did actually run (5698 instead of 11266), so build 743 might be the first one where the managedbuild and codan tests did run for the first time.
(In reply to comment #11) > (In reply to comment #9) > > It that this change that causes +55 Unit test failures on Hudson? > https://hudson.eclipse.org/hudson/job/cdt-nightly/lastCompletedBuild/testReport/ > I doubt it very much. I cannot see how this change would trigger those failures. > Nevertheless I have rerun the managedbuild.core tests and the result is the same > with or without this change (5 failures). > Looking at the test results of build 741, it seems only half of all tests did > actually run (5698 instead of 11266), so build 743 might be the first one where > the managedbuild and codan tests did run for the first time. It appears that the tests haven't been setup to run in "JUnit Plugin Tests" mode on Hudson yet, sorry for false alarm.
