The general answer is to take it on a case-by-case basis. For some modelling tasks one can have hierarchies where base classes are usable. GUI related ones come into mind as a prime candidate. One has a Button class, which gives you a standard button. But one also has a SubmitButton class, which is derived from Button, and makes the button look all fancy, but still needs the behaviours of Button. So, it makes sense to use one or the other, depending on the circumstance, and not worry about NonSubmitButtons.
On the other hand, a hierarchy of connections classes for different databases would not allow such usage. You'd have your Connection class, which is derived by MySQLConnection, PostgresConnection etc. It doesn't make sense to construct a generic connection - just to work with one.
I think your case falls in the former, rather than the latter, case.
On the other hand, you could ditch the concept of a hierarchy of classes completely if the situation escalates. For example, if you'd want to represent archived files, files stored on remote servers, procfs style files etc, you'd need a pretty big hierarchy. If a file could be any of the above, you'd quickly have an unwieldy hierarchy - things like FileWithIntegrityAndOnARemoteServer looks quite bad. For cases like this, you can store the extra properties as actual properties of the class. For any one file, the properties are optional, but for files with integrity checks, the appropriate property is present etc. It's an instance of the composition over inheritance idea.
