mirror of
https://github.com/kdave/btrfs-progs
synced 2025-04-23 23:45:20 +00:00
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');
|
putchar('\n');
|
||||||
return 0;
|
return 0;
|
||||||
}
|
}
|
||||||
/* Short paths ale aligned to 32 chars */
|
/* Short paths are aligned to 32 chars; longer paths get a single space */
|
||||||
while (ret++ < 32)
|
do {
|
||||||
putchar(' ');
|
putchar(' ');
|
||||||
|
} while (++ret < 32);
|
||||||
va_start(args, fmt);
|
va_start(args, fmt);
|
||||||
/* Operation specified ones */
|
/* Operation specified ones */
|
||||||
vprintf(fmt, args);
|
vprintf(fmt, args);
|
||||||
|
Loading…
Reference in New Issue
Block a user