ext2simg: Fix off-by-one errors causing corruption #116
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
If your filesystem is contiguously used from block 0 to block 524286
with a 4096 byte block size, block 524286 did not end up in the sparse
image and was thus restored as zeros when unsparsing.
Additionally, if the last block of the image is used, this block also
ended up being 0:
$> dd if=/dev/zero of=test.ext4 bs=4096 count=10240
$> mkfs.ext4 test.ext4
$> mkdir test
$> sudo mount -t ext4 -o loop test.ext4 test
$> sudo dd if=/dev/urandom of=test/contents
$> sudo umount test
$> ext2simg test.ext4 test.ext4.simg
$> simg2img test.ext4.simg test.ext4.restored
$> vimdiff <(debugfs -R 'bd 10239' test.ext4) <(debugfs -R 'bd 10239' test.ext4.restored)
This seems to have happened because it was not clear that add_chunk()
treats the given end block as exclusive, since the different invocations
of add_chunk() seem to make different assumptions on whether the end
block is included in the sparse image or not. Add documentation to both
the add_chunk function as well as the invocations to clarify this.
This may or may not be the same issue that was reported a few years ago
in https://www.spinics.net/lists/linux-ext4/msg58483.html.
Signed-off-by: Clemens Lang clemens.lang@xxxxxx