Does it even make sense to have swap as a filesystem?

I'm all for parsers and such, so that's a great contribution, but maybe it's more suited as a specific parser rather than a general purpose filesystem implementation?

If we got to the point where all properties and features were mapped, it seems to me that it would just be a load of dummy implementations for the Vfs system and then a few extra methods for reading and writing pages..

The idea is to be able to detect whatever is on a given disk or image (and for example render something like this).

Without support for Swap detection, we can't tell if there is something useful on the partition - with swap support we can at least say that it's a valid swap with a given size (which may differ from the partition size - don't know why anyone would do this) and that there may a data loss if someone modifies the content of this partition.

So the idea is to be able to make an informed decision depending on the current content of any disk, partition, image, whatever.

I've added another commit, which removes the dummy implementation and derives directly from VfsReadonlyFileSystem.

Wouldn't it be better to use the partition table systems (MBR, GPT) and list partitions from there?

Having it as a RO fs is better in any case :)

@qmfrederik any input?

@qmfrederik poke?

The way I understand this PR is that it allows you to inspect very basic properties of the swap filesystem (basically the header), which complement the information you get from the MBR/GPT.

So there's value in the PR (plus it has a unit test!) which makes say - "why not"?

There does seem to be some overhead in creating a separate NuGet package for just a couple of classes; but that is just a side effect of factoring everything into separate packages, so that should be OK, too.

Net: LGTM :)