Bug 309967 - Cache read-only and symlink state in ResourceInfo
Summary: Cache read-only and symlink state in ResourceInfo
Status: NEW
Alias: None
Product: Platform
Classification: Eclipse Project
Component: Resources (show other bugs)
Version: 3.6   Edit
Hardware: All All
: P3 enhancement (vote)
Target Milestone: ---   Edit
Assignee: Platform-Resources-Inbox CLA
QA Contact:
URL:
Whiteboard:
Keywords: performance
: 351953 (view as bug list)
Depends on:
Blocks: 198291
  Show dependency tree
 
Reported: 2010-04-21 10:11 EDT by Martin Oberhuber CLA
Modified: 2011-07-19 15:44 EDT (History)
2 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Martin Oberhuber CLA 2010-04-21 10:11:23 EDT
User Story:
As a user of an Eclipse based IDE who's working on very large projects, I want to apply a viewer filter that quickly shows only writable files, such that I can concentrate on the files I have modified.

We've had this feature in previous (non Eclipse based) tools using a file system cache, and it was widely used. In Eclipse though, the current Resources implementation requires such a "read-only filter" to call getResourceAttributes() for every element. On a project with 60000 files in total, of which only 10 are writable, this does not scale. Especially on a slow file system like a Clearcase dynamic view, a network share or an EFS shared web folder, just getting the fstat() of 60000 files can take minutes, which is not acceptable.

It would seem straightforward to have the refreshLocal() operation, which reads file state anyways, cache that information in the ResourceInfo object along with the modification timestamp. Optionally, this would also enable resource change events when read-only state changes on a refresh, such that viewers/filters can listen to such changes.

If adding read-only state to the ResourceInfo is being considered, adding the "is symbolic link" information to the ResourceInfo should be considered as well. Knowing what elements are actually symbolic links is critical for tracking aliasing through symbolic links as per bug 198291.
Comment 1 John Arthorne CLA 2011-07-19 15:44:54 EDT
*** Bug 351953 has been marked as a duplicate of this bug. ***