On 30/03/2010 19:34, johan...@opensolaris.org wrote:
On Tue, Mar 30, 2010 at 10:31:04AM -0700, Bart Smaalders wrote:
On 03/30/10 09:58, Glenn Brunette wrote:
Dan,
I have to +1 all of your well-thought-out comments. As a potential
consuming of this functionality for the Immutable Service Container
project, answers to these questions are critical.
I am also interested in whether additional fields can be added to
the output similar to a "-o field1,field2" scenario? It would be
nice to have data such as file type, modification time (where
applicable).
Also, will this functionality be able to tell how files were modified?
Things like changes in file ownership, group membership, permissions
and ACLs, size, times, etc.? Even if this processing is not directly
implemented as part of the zfs diff command, perhaps the fields could
be made available (per -o comment above) to be consumed by layered
tools?
A very detailed human readable diff of file attributes seems a lot of
additional work to place on zfs diff. Isn't a list of what is different
sufficient to give to another program?
This portion of the discussion makes me wonder if there would be some
value in developing a prototype of 'zfs patch'. Designing patch might
help illuminate some of the attributes that should be machine-readable
by default. If certain portions of the diff/patch implementation are
For 'zfs patch' to be useful it would need to include the data as well
not just the metadata. That is exactly what 'zfs send | zfs recv' is.
--
Darren J Moffat
_______________________________________________
opensolaris-arc mailing list
opensolaris-arc@opensolaris.org
