I was shocked to discover that 'btrfs receive --dump' doesn't print a
space after long filenames, so it runs together into the metadata; for
example:
truncate ./20-00-03/this-name-is-32-characters-longsize=0
This is a trivial patch to add a single space unconditionally, so the
result is the following:
truncate ./20-00-03/this-name-is-32-characters-long size=0
I suppose this is technically a breaking change, but it seems unlikely
to me that anyone would depend on the existing behavior given how
unfriendly it is.
Signed-off-by: Evan Danaher <github@edanaher.net>
Reviewed-by: Noah Massey <noah.massey@gmail.com>
Signed-off-by: David Sterba <dsterba@suse.com>
The send dump prints one line per stream operation, we'd like to prevent
any line breakage, so the characters are printed escaped in the C style.
Signed-off-by: David Sterba <dsterba@suse.com>
Introduce send-dump.[ch] which implements a new btrfs_send_ops to
exam and output all operations inside a send stream.
It has a better output format than the old and no longer compilable
send-test tool, but still tries to be script friendly.
Provides the basis for later "inspect-internal dump-send" command.
Signed-off-by: Qu Wenruo <quwenruo@cn.fujitsu.com>
[ drop escaping call from __print_dump for now, drop gcc warning tweaks,
replace empty format strings with NULL ]
Signed-off-by: David Sterba <dsterba@suse.com>
David Sterba
Josh Soref
Evan Danaher
Benedikt Morbach
Qu Wenruo