Community
Participate
Working Groups
Build ID: M20060921-0945 Steps To Reproduce: IProject myProject = ...the current project IFolder folder = myProject.getFolder("somefolder"); folder.createLink(path to network drive with lots of files); (The last call may take ~10-15 mtinutes on a rather quick network drive with ~5-6000 files in a complex direcory tree) More information: The problem here is that Resource.createLink() on a folder automatically calls refreshLocal() with DEPTH_INFINITE (Resource.java, line 610). While this might be a reasonable default for most cases, there should be an option to do the refresh with a specified depth, e.g. (new overloaded method): IFolder.createLink(IPath location, int updateFlags, int refreshDepth, IProgressMonitor monitor) Double checked with 3.3M4 source and the code looks exactly the same.
This is specified behaviour of IFolder#createLink: "This method synchronizes this resource with the local file system at the given location." We cannot break the spec, but we could explore adding support for performing this refresh in a background thread. A similar strategy was adopted for IProject#open (see bug 74392).
(In reply to comment #1) > We cannot break the spec... > I certainly agree that you shouldn't break the spec of the existing method, however adding a new overloaded method signature with a slightly different spec, e.g. "This method synchronizes this resource to the specified depth...", would not break the spec of the existing method, correct? If the background refresh approach would enable my users to start working while the refresh is running, I'm sure that would be much better than the current situation. But they will still have to wait for the automatic refresh to reach the part of the tree where they would like to start working, right? Say I create links to five network folders. If I do this with a refreshLocal(DEPTH_ONE) (I did a patch myself just to try it out) the calls to createLink() return almost immediately, and then it's up to the user to click the folder he wants to work with, which will start a refresh of that folder. If the refresh was to happen in the background, but still with DEPTH_INFINITE, would the refresh jobs for each folder be queued or would they run conurrently? If they would be queued the situation wouldn't be much better than the current one, i.e. the second folder wouldn't appear until the refresh of the first one finished, am I correct? I still think that an on-demand refresh of the folders would be preferred.
Background refresh works using a single global refresh queue, and one background job that services that queue. When a client specifically requests the children of a container whose children have not yet been discovered, the resource is moved to the front of the queue so that it will be refreshed at the next opportunity. In the absence of explicit requests for children, the job proceeds to refresh containers in a breadth-first manner.
Excellent, that would do the trick. Do you have any estimate of in what version this might be fixed?
Created attachment 60063 [details] bugfix this is my proposal of changes that will enable BACKGROUND_REFRESH option. i've also created benchmark plugin (it is based on benchmark from IProject#open) i can attach it if needed
Excellent, this seems to do the trick. Any estimate of what target version this might be included in?
Thanks Bartosz! I will review the patch.
Bartosz, how would you like to be attributed in the copyright statement? Just your name and email?
Created attachment 60806 [details] Updated patch (javadoc typos, cleanup)
Created attachment 60807 [details] JUnit test
Fix released.
