Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 342968

Summary:

Resource layers asks IFileTree for info of linked resources

Product:

[Eclipse Project] Platform

Reporter:

Michael Valenta <Michael.Valenta>

Component:

Resources

Assignee:

Serge Beauchamp <serge>

Status:

RESOLVED FIXED

QA Contact:

Severity:

normal

Priority:

CC:

arthorne.eclipse, remy.suen, serge

Version:

3.5

Target Milestone:

3.7

Hardware:

OS:

Windows 7

Whiteboard:

Attachments:

Description	Flags
Zipped test case bundle	none
patch	none
Fix and junit test	none

Description Michael Valenta

2011-04-15 09:29:47 EDT

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

Comment 1 Michael Valenta

2011-04-15 09:30:47 EDT

Created attachment 193368 [details]
Zipped test case bundle

Here's the zipped bundle that contains the failing test case.

Comment 2 Serge Beauchamp

2011-04-15 11:50:30 EDT

Created attachment 193385 [details]
patch

Here's a patch to address the problem.

Comment 3 Serge Beauchamp

2011-04-15 11:53:08 EDT

John, could you review the fix to see if the fix I proposed is appropriate?  

thanks,

Comment 4 John Arthorne

2011-04-15 16:59:48 EDT

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).

Comment 5 Serge Beauchamp

2011-04-19 05:23:27 EDT

(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?

Comment 6 Szymon Brandys

2011-04-19 05:55:08 EDT

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.

Comment 7 John Arthorne

2011-04-19 08:45:33 EDT

(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.

Comment 8 Serge Beauchamp

2011-04-19 09:40:33 EDT

> 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.

Comment 9 Serge Beauchamp

2011-04-19 09:41:04 EDT

Created attachment 193580 [details]
Fix and junit test

Comment 10 John Arthorne

2011-04-19 10:35:24 EDT

Looks good to me, Serge. Release away...

Comment 11 Serge Beauchamp

2011-04-20 01:50:03 EDT

This bug is now fixed on the trunk.