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 <git...@edanaher.net>
---
diff --git a/send-dump.c b/send-dump.c
index 67f7977..1591e0c 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);
va_start(args, fmt);
/* Operation specified ones */
vprintf(fmt, args);
---
Thanks to Noah Massey for catching an off-by-one; I had kept the
condition as (ret++ < 32), but that would pad to 33 spaces, not 32.
Changing the loop condition to preincrement keeps the old behavior for
short names.
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
