Ping @jterry75 @kevpar

What would be the authoritative source? MSDN?

Empirical observation, sadly. These are overlay registry hives that get created once a layer is committed with the changes that happened in that particular layer. But there is no publicly available documentation for this, or at least none that I could find.

Perhaps if we ignored the entire WcSandboxState undocumented/OS-use folder recursively somehow (is that bool used for anything right now?) then we'd be safe from any internal changes made in the future. System Volume Information would probably also make sense to ignore recursively. These are akin to lost+found in ext3, in that they're OS-managed and may be modified by apparently-unrelated user action, and so probably never make sense to compare.

The registry hive list in Windows/system32/config is pretty fixed, as they need to exist in a base layer as part of its creation. For those, we have the code in hcshim that can create non-bootable empty-but-valid instances. That's also empirical observation, but in an MS-owned project at least, and with unit tests. And I suspect changing the number or names of registry hives in Windows at this point would take decades to unwind, given that they've been unchanged AFAIR since the 1990's.

is that bool used for anything right now?

It's used here: https://github.com/containerd/continuity/blob/main/fs/fstest/continuity_util.go#L49-L53

If missing or explicitly set to false, HasDiff() will return true.

Perhaps if we ignored the entire WcSandboxState undocumented/OS-use folder recursively somehow

Being able to recursively ignore a folder would be great, but I think that should be part of a different PR. It may be useful on both Windows and Linux, in the future.

Going to go ahead and merge this for now; if there are future improvements to managing the metadata list we can handle with a follow-up PR.