btrfs-progs: send: always print a space after path in dump

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>
This commit is contained in:
Evan Danaher 2017-04-11 12:33:40 -04:00 committed by David Sterba
parent 57909d702c
commit beb924e12d
1 changed files with 3 additions and 2 deletions

View File

@ -116,9 +116,10 @@ static int __print_dump(int subvol, void *user, const char *path,
putchar('\n');
return 0;
}
/* Short paths ale aligned to 32 chars */
while (ret++ < 32)
/* Short paths are aligned to 32 chars; longer paths get a single space */
do {
putchar(' ');
} while (++ret < 32);
va_start(args, fmt);
/* Operation specified ones */
vprintf(fmt, args);