On Mon 29 Mar 2010 at 11:14AM, Bart Smaalders wrote: > On 03/29/10 11:01, Matthew Ahrens wrote: > > >How do commands like ls and find handle printing of filenames with > >arbitrary characters (newlines and such)? > > In general, badly.
Tim, My concern, which others have hinted at, is that there are a legion of people who are going to want to consume this information and there is great value in making said information be machine parseable. Automated build systems, tripwires, fancy backup/recovery tools, et cetera. In summary, the current output seems mostly OK if it's for humans, but the case is ambiguous about who the expected consumer is. It would be a tragedy if there wasn't a machine consumable way to get at this information. 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). 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? 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: snapshot at 1 rm a/b rm a/c rmdir a echo "foo" > a snapshot at 2 Does that yield this? Or this? - a/b | - a/b - a/c | - a/c - a | M a + a | 3) Output is shown with leading slashes. Is output shown relative to the mount point? Or something else? (If the former, what if between @a and @b the mountpoint changed?) 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 Thanks for tackling this, -dp -- Daniel Price, Solaris Kernel Engineering http://blogs.sun.com/dp