On 1/7/13 3:37 PM, Ben Myers wrote:
> Hmm. I agree with Eric that it is likely related to 'xfsdump: fill in
> bs_forkoff', commit b7af332b. Maybe bumping the dump version was the right
> thing to do back then. 3.1.2 should work fine though.
This should fix it, so future dumps are still compatible w/ earlier restores.
At this point I don't know WTF to do w/ versioning etc to best contain the
[PATCH] xfsdump: zero bs_forkoff, don't fill in the value
In xfsdump 3.1.2 I explicitly added the bs_forkoff member
to this structure; I tried to be good and explicitly fill
in a value. However, previously it was initialized to
zero, and now we're giving it a value (which is ignored
by restore, other than to checksum it).
By putting in a non-zero value, I broke checksumming
when an xfsdump with a non-zero forkoff was restored
by an older xfsrestore that doesn't know about the field.
Fill in 0 to fix backwards compatibility.
Signed-off-by: Eric Sandeen <sandeen@xxxxxxxxxx>
Reported-by: Fugazzi99 <fugazzi99@xxxxxxxxx>
diff --git a/dump/content.c b/dump/content.c
index 9a36fe1..ac19021 100644
@@ -4928,7 +4928,7 @@ copy_xfs_bstat(bstat_t *dst, xfs_bstat_t *src)
dst->bs_extents = src->bs_extents;
dst->bs_gen = src->bs_gen;
dst->bs_projid_lo = src->bs_projid_lo;
- dst->bs_forkoff = src->bs_forkoff;
+ dst->bs_forkoff = 0;
dst->bs_projid_hi = src->bs_projid_hi;
dst->bs_dmevmask = src->bs_dmevmask;
dst->bs_dmstate = src->bs_dmstate;