Community
Participate
Working Groups
A useful feature would be the ability to turn off refresh on specific directories within a project, without having to turn off automatic refresh. This could be used to prevent Eclipse from unnecessarily trying to refresh, say, local temporary directories, or large data collections if there is a symlink to those within the project directory structure.
Similar to bug 244979.
In 3.6 you can now specify filters to exclude sub-trees from the workspace, based on name or some pattern. Is this what you are looking for? Including a folder but disabling refresh seems dangerous because we would end up showing a structure that doesn't match at all what's in the file system.
(In reply to comment #2) > In 3.6 you can now specify filters to exclude sub-trees from the workspace, > based on name or some pattern. Is this what you are looking for? It is what we are looking for to prevent multi hour refreshes. We implemented our own FileSystem class as a short term fix. We are scaling our RCP based 3D processing system to handle extremely large data volumes. It will be common to see a +100,000 files in a single folder and have a workspace consume 20 TB of data. http://richclientplatform.blogspot.com/2007/12/oil-and-gas-industry-using-eclipse.html
(In reply to comment #3) > (In reply to comment #2) > > In 3.6 you can now specify filters to exclude sub-trees from the workspace, > > based on name or some pattern. Is this what you are looking for? > > It is what we are looking for to prevent multi hour refreshes. So the new feature satisfy you, right? Or there is something more you need?
> So the new feature satisfy you, right? Yes. > Or there is something more you need? No. Setting one or more patterns so the FileSystem will not return the contents of the folder. I have no problem with the folder appearing in the workspace since there are already features to filter out the IResource. Our current 'fix' will return the name of the folder but not its contents. This is done in our implementation of FileSystem#childNames(int, IProgressMonitor).
> So the new feature satisfy you, right? Sorry, I answered to quickly. I'm downloading Eclipse 3.6M4 right now and I will look at the code and get back to you as quick as I can.
(In reply to comment #6) > > So the new feature satisfy you, right? > Sorry, I answered to quickly. I'm downloading Eclipse 3.6M4 right now and I > will look at the code and get back to you as quick as I can. The existing Eclipse 3.6M4 does not work for us. The new feature, nice as it is, still allows the workspace to find out how many files the hidden folder contains. Create a folder with 100,000 files and you will see LocalFile.childNames(int, IProgressMonitor) is still calling File.list(). Scale up the workspace to a tens of millions of files and the workspace becomes unusable. We need to be able to filter a group of folders and their sub folders from the workspace. For the curious, we use a light weight database to manage these hidden folders and files. The hidden files are opened as if they are external files to the workspace. It works extremely well and avoids the three to four hour refresh consuming +2 GB of memory.
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant.
This bug still seems relevant. Doing JS development in Eclipse is very painful. Doing a JS build results in Eclipse running at 100% for minutes. Filtering out the build files has no effect.
