Re: [PATCH] btrfs-progs: send-dump: always print a space after path

[Noah Massey <noah.massey@gmail.com>]

On Mon, Apr 10, 2017 at 8:09 PM, Evan Danaher <github@edanaher.net> 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 <github@edanaher.net>
> ---
> 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 majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html