On Mon, Apr 10, 2017 at 8:09 PM, Evan Danaher <[email protected]> wrote: > 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 <[email protected]> > --- > diff --git a/send-dump.c b/send-dump.c > index 67f7977..493389f 100644 > --- a/send-dump.c > +++ b/send-dump.c > @@ -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);
while (++ret < 32); Since we're performing the check after the put, we need to pre-increment to count the space already added. > va_start(args, fmt); > /* Operation specified ones */ > vprintf(fmt, args); > --- > -- > To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in > the body of a message to [email protected] > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
