Community
Participate
Working Groups
Build Identifier: Eclipse 3.5.2 We use a custom EFS for projects mapped to our repository provider. We implement the IFileSystem#fetchFileTree to optimize the refresh. Unfortunately, this breaks when the project contains Eclipse level links because the Resource layer asks our IFileTree for information about the files from the other Filesystem provider. i will attach a test plug-in that illustrates the problem. Reproducible: Always Steps to Reproduce: 1. Load attached bundle into your workspace 2. Run the RefrestTest test case 3. See that the files within the link are removed from the resource tree because the TestRefreshFileTree only provides information about it's own file stores
Created attachment 193368 [details] Zipped test case bundle Here's the zipped bundle that contains the failing test case.
Created attachment 193385 [details] patch Here's a patch to address the problem.
John, could you review the fix to see if the fix I proposed is appropriate? thanks,
The fix doesn't seem sufficient. Maybe the file system is the same, but the link points outside the tree described by the provided IFileTree. I think we would need something like: if (fileTree != null && fileTree.getTreeRoot().isParentOf(store)) We could optimize further by fetching the fileTree for each linked resource we come across, but I would worry about the memory overhead of that (we do breadth-first traversal here).
(In reply to comment #4) > The fix doesn't seem sufficient. Maybe the file system is the same, but the > link points outside the tree described by the provided IFileTree. > > I think we would need something like: > > if (fileTree != null && fileTree.getTreeRoot().isParentOf(store)) > > We could optimize further by fetching the fileTree for each linked resource we > come across, but I would worry about the memory overhead of that (we do > breadth-first traversal here). Hum, I see. So, since because of linked resources, the file infos can come from any other file system, to be consistent with the design of creating a file tree snapshot for the refresh operation, we'd need to create (and keep, if other linked resources point to the same file tree)) a filetree for each new file system encountered during the refresh operation? I suppose there's not really a way around it, right?
At this point, if there is any bug planned for 3.7 or 3.7 M7 please add an assignee. I guess it is Serge.
(In reply to comment #5) > So, since because of linked resources, the file infos can come from any other > file system, to be consistent with the design of creating a file tree snapshot > for the refresh operation, we'd need to create (and keep, if other linked > resources point to the same file tree)) a filetree for each new file system > encountered during the refresh operation? > > I suppose there's not really a way around it, right? Currently we have a bug because we consult a file tree from the wrong file system. That is the most important thing to fix. We could fix that by falling back to IFileStore#fetchInfo for any IFileStore not under the file tree we have in hand. There is a more complex solution where we keep track of the file tree for each file system root, as you say. Likely the best way to do this is to store the file tree in UnifiedTreeNode for each node that does not share a file system with its parent. I think it would be ok to defer this part and just focus on the bug fix for right now. Serge, let me know if you can handle this. If not, I can take it. Since it is M7 next week it would be best to get it fixed this week.
> Currently we have a bug because we consult a file tree from the wrong file > system. That is the most important thing to fix. We could fix that by falling > back to IFileStore#fetchInfo for any IFileStore not under the file tree we have > in hand. > > There is a more complex solution where we keep track of the file tree for each > file system root, as you say. Likely the best way to do this is to store the > file tree in UnifiedTreeNode for each node that does not share a file system > with its parent. I think it would be ok to defer this part and just focus on > the bug fix for right now. > > Serge, let me know if you can handle this. If not, I can take it. Since it is > M7 next week it would be best to get it fixed this week. Ok, fair enough, I attached a new fix with your recommendation, along with a test case refactored from Michael's one. Can you review it for me please? Thanks.
Created attachment 193580 [details] Fix and junit test
Looks good to me, Serge. Release away...
This bug is now fixed on the trunk.
