FWIW, I never intended for this DirCacheEntry class to be responsible for this sort of status check code.  I meant for this to go into some other new class that was running a TreeWalk of some sort over a FileTreeIterator and a DirCacheIterator.

For example, FileTreeIterator already has the ability to compute the ObjectId of the file on the fly.  This is derived through the WorkingTreeIterator base class.

By doing this sort of stuff through the WorkingTreeIterator, we can use the Eclipse IResource APIs to access the files when inside of EGit, rather than relying on java.io.File.  This means we could rely on the Eclipse stat cache rather than always hitting stat() on the filesystem, and we could make use of the IResource APIs to modify the files, so the workbench would be properly notified of any edits we make.

Relying on WorkingTreeIterator might also simplify some of the logic around the mode test.  Its already converted the filesystem mode into the raw mode format we use in the index, making direct compares easier.