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:
parent
57909d702c
commit
beb924e12d
|
@ -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);
|
||||
|
|
Loading…
Reference in New Issue