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 kept in shared libraries, it would prevent different consumers of the diff output from having to re-implement the same basic functions over and over again. Since it sounds like a lot of teams are interested in using this functionality, it may be worth investigating. Having some of the diff/patch shared would also allow the underlying implementation to change over time, as long as consumers linked with the proper shared libraries. This is orthogonal to the current discussion, but it seemed worth mentioning. -j
