path: root/send-dump.c
diff options
authorEvan Danaher <>2017-04-11 12:33:40 -0400
committerDavid Sterba <>2017-04-19 19:33:43 +0200
commitbeb924e12d33f11d76c54fad003c6ae3adc9fcc7 (patch)
tree19110e9623489d8886ad5107d341f889fdd61ae7 /send-dump.c
parent57909d702c4d636a5f733309202c36fe006d84e9 (diff)
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 <> Reviewed-by: Noah Massey <> Signed-off-by: David Sterba <>
Diffstat (limited to 'send-dump.c')
1 files changed, 3 insertions, 2 deletions
diff --git a/send-dump.c b/send-dump.c
index 67f79779..1591e0cc 100644
--- a/send-dump.c
+++ b/send-dump.c
@@ -116,9 +116,10 @@ static int __print_dump(int subvol, void *user, const char *path,
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);