[fhs-discuss] should we be/set-up a registry for xattr name[spaces]

Christoph Anton Mitterer calestyo at scientia.net
Sat May 14 16:51:05 PDT 2011


Hi.

This is not directly file HIERARCHY related, but it might be of interest
for us.

Many filesystems support XATTRs,... but currently there is not place (at
least none that I'd know) where the namespace is managed.
There is http://www.freedesktop.org/wiki/CommonExtendedAttributes but this
is rather guidelines, though the ideas there are definitley good
(especially the reverse-DNS user namespace).
One problem of them is, that they already started putting non-DNS
namespaces in the user. hierarchy, which is IMHO quite dangerous, given
that the root zone will/might eventually open up for public registrations.
And it's e.g. not impossible that someone reserves the "xdg." TLD.

So maybe FHS could be the registry for XATTR namespaces, and could even
put attributes of general use (and which are guaranteed to last more or
less forever) in the root. Examples:

1) user. hiarchy:
For general use, a reverse-DNS namespace must be added after "user." and
before any (optional) attributes.

2) oid. hierarchy:
Analogous to (1), but using OIDs as namspace, e.g.
"1.3.6.1.4.1.32806.my_personal_attribute"

3) hashsum.complete.<algorithm name>
Where algorithm name is e.g. SHA512, MD5, etc. (we'd need a registry for
algorithm names)... and where the value is the hash sum of the complete
respective file (in that algorithm).

In addition perhaps:
hashsum.<number>.<algorithm name>
hashsum.<number>.<offset>
hashsum.<number>.<lenght>
to allow chunking of a file.

4) owner.user, owner.group
creator
pathname
date.creation
date.modified
...
(yes I know, that these already exist as "normal" attributes, but it might
still make sense to have them, e.g. when moving to a filesystem that
doesn't support them, e.g. rsync does this already)


Cheers,
Chris.


More information about the fhs-discuss mailing list