On 3/29/10 10:54 PM, Dan Price wrote:
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'm adding a -H option for scripting, with parseable output.
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?
This got clarified, I believe.
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:
snaps...@1
rm a/b
rm a/c
rmdir a
echo "foo"> a
snaps...@2
Does that yield this? Or this?
- a/b | - a/b
- a/c | - a/c
- a | M a
+ a |
We are tracking the actual file objects. Running your test with the
current code:
M /files/
- /files/a
- /files/a/b
- /files/a/c
+ /files/a
Having slept on this, I think an extra field in the output will help. A
type character
could be added to another column, using the same sorts of symbols that
ls -F shows,
@ for symbolic link, / for directory, | for pipe, etc. Plus
an 'F' to indicate a regular file. So the above would become:
M /files/ /
- /files/a F
- /files/a/b F
- /files/a/c F
+ /files/a F
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?)
The output shown is relative to where the dataset is mounted at the time
of the diff.
We don't necessarily know where it was mounted at the time of any
particular snapshot.
You are correct that the command should work with clones, too, as though
are desendant.
For a clone we'd present its paths relative to where it is mounted.
-tim
_______________________________________________
opensolaris-arc mailing list
[email protected]
