It is desired to provide protected methods as hooks to allow subclasses more nuanced handling of file resources.

The immediate motivation is the fact that sometimes useful/actionable information is encoded even in a "broken" symbolic link (e.g., git-annex). It appears that the FileSystemConnector can be minimally refactored to allow it to serve as a more general-purpose base-class connector for representing filesystem information as jcr nodes. This should not affect existing behavior, but would support much more flexible reuse and extension.

This change would effectively revisit the decision (forced by absence of symbolic link awareness in Java 6) to simply rely on File "existence" to determine inclusion in the exposed tree (see MODE-1482).