On Mon, Mar 29, 2010 at 09:54:01PM -0700, Dan Price wrote: > I also have questions about how intelligent a consuming piece of > software must be in order to make sense of this information. Has anyone > written a proof of concept tool using this? For example, if a directory > /foo/a is renamed to /foo/b, then an analyzer would need to stat /foo/b > in order to discover that /foo/b is a directory, then traverse into as > needed. It would be a shame if everyone who wanted to consume this had > to write the same thousand lines of code (I'm happy to be convinced that > this isn't the case).
Using simple backslash escaping works well with the shell's read built-in. Backslash octal escaping also works well with the shell's read built-in using the -r option (but not with /usr/has/bin/sh, which has no -r option). I'm happy with octal escapes for shell scripting. For other purposes one might really like HTML/XML entities (e.g., '&'), but I don't expect the i-team will want to cater to every developer :/ Instead, an API would be nice, since an API could completely avoid any ambiguity directly. That could come later. > Some specific questions... > > 1) In what order are the changes printed? If I saw: > > + /myfiles/rename_dir > R /myfiles/rename_dir -> /myfiles/rename_dir > > My analyzer would need to be smart enough to realize that the second > must have happened before the first, and that both paths need > evaluation. Right? Between two snapshots only the later event would be found, surely. (But I'm not the i-team.) > 2) The meaning of "file/directory" (Don's concern aside) seems ambiguous in > the proposal. Are we tracking the filesystem *namespace* entry? Or the > actual object? I found that not being sure of this made the proposal > hard to evaluate. Simple thought experiment which confused me: A related question: what about zero-link files that were open at the time that a snapshot was taken? Presumably there's no need to even mention their existence since they can't be accessed by the consumer. > 4) I would also vote for a mode which simply outputs a list of > pathnames to investigate for differences. This would enable: > > zfs diff -someflag a at 1 a at 2 | xargs do_some_analysis_on_these If you're going to target xargs then definitely, definitely include a GNU find-like -print0 option to match xargs' -0 option. That completely avoids ambiguity. (And, of course, for renames output only the new name.) Nico --
