I'm probably not the first to suggest this idea, and it's probably not a very good idea, but here's my idea anyhow:And the problem with such a "solution" is
You have a file "/usr/bin/emacs"
with a metadata property in the overlaid namespace "/usr/bin/emacs/[[..]metas/]icon"
According to some, this could cause some confusion. Howabout instead:
You have a file "/usr/bin/emacs"
with a metadata property in a slightly separated namespace "/metas/usr/bin/emacs/icon"
This has the advantage of still having the metadata in the filesystem namespace but without the confusion of having files-as-directories, ambiguity of filename, backup issues, etc. This is the reverse of having the namespaces overlaid with a "/nometas" view which is separate.
Furthermore, you can split things further like this:
You have a file "/usr/bin/emacs"
with an automatically-generated metadata property that you don't want to back up in "/autometas/usr/bin/emacs/modification_date"
and a manually generated metadata property that you MAY want to backup in "/staticmetas/usr/bin/emacs/icon".
This is inelegant, I know. But if we do this, we can add the extra features of reiser4 without confusing existing apps or having to modify them to support the new functionality.
Furthermore, you can easily hide the extra features by not mounting the meta top-level directories (assuming they're mounted like separate filesystems, rather than just magically appearing there, which is okay too).