[Gnu-arch-users] extended attribute tracking

[Johannes Berg]

Hi,

Here are some ideas for extended attribute tracking, I'm just throwing
them in for comments before attempting to implement. 

First off -- does anyone think this is desirable at all? Or just a
stupid idea I'm having here?

Anyway, here I go:

extended attributes have their own namespace, somewhat like dirs:
   user.mime_type
   system.posix_acl_access
   ...
There can be arbitrary data attached to each item, and each item should
be handled separately. The question is what should happen to the content
of the extended attribute. Maybe it would suffice to just copy it over,
but it would probably be possible to diff it as well. In the case of
ACLs, that wouldn't help much, because they're just a single line (for
all I've seen).
It would be possible to pick ACLs apart, but I'm not sure how feasible
this is. I don't think they should be.

The storage in changesets needs to take into account the name of an
attribute and also the fact that it can contain binary data.

Here's a proposal:
Pretend that each attribute that is present is just another file that
can be diffed. These will always have the tagging method "names". They
are diffed just like normal files (need to save temp files for this).

I'm not sure how to store these things into the changeset while keeping
it simple yet avoid possible clashes with names.
Maybe a new "xattr" directory should be added to the changeset, which
only keeps information about attributes. All files within that tree are
either .patch files or .{original,modified} pairs depending on whether
the attribute value was binary or text. 
If an attribute belongs to a file, then a directory is created whereever
the file belongs that has the name of the file, and files below it
belong to its attributes. For directories, it is possible to have both
files and dirs below it (the dirs belong to other dirs/files below
them).

The names of the .{patch,original,modified} files will need to be
encoded to avoid problems with slashes or binary names. This should be
something that is invariant if you don't use binary or slashes in the
name, maybe something like URL encoding.

Conflict resolution will likely consist in saving old and new value or
patch and letting the user decide on an attribute basis.

Oh, and for those file systems that don't have EA just don't do
anything, don't create patches because they're gone all of a sudden etc.

johannes
-- 
http://www.sipsolutions.de/
GnuPG key: http://www.sipsolutions.de/keys/JohannesBerg.asc
  Key-ID: 9AB78CA5 Johannes Berg <address@hidden>
  Fingerprint = AD02 0176 4E29 C137 1DF6 08D2 FC44 CF86 9AB7 8CA5

signature.asc
Description: This is a digitally signed message part