mismatch between implementation and documentation of bmap path discovery strategy

[josch]

The documentation states:

bmaptool automatically discovers it by looking for a file with the same basename as IMAGE but with the ".bmap" extension.

Lets try this out:

$ echo foo > foo.img
$ echo bar > bar.img
$ bmaptool create foo.img > foo.bmap
$ bmaptool create bar.img > foo.img.bmap
$ bmaptool copy foo.img disk
bmaptool: info: discovered bmap file 'foo.img.bmap'
bmaptool: info: block map format version 2.0
bmaptool: info: 1 blocks of size 4096 (4 bytes), mapped 1 blocks (4.0 KiB or 100.0%)
bmaptool: info: copying image 'foo.img' to file 'disk' using bmap file 'foo.img.bmap'
bmaptool: info: 100% copied
bmaptool: ERROR: An error occurred, here is the traceback:
Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/bmaptools/CLI.py", line 490, in copy_command
    writer.copy(False, not args.no_verify)
  File "/usr/lib/python3/dist-packages/bmaptools/BmapCopy.py", line 617, in copy
    reraise(exc_info[0], exc_info[1], exc_info[2])
  File "/usr/lib/python3/dist-packages/six.py", line 719, in reraise
    raise value
  File "/usr/lib/python3/dist-packages/bmaptools/BmapCopy.py", line 562, in _get_data
    raise Error("checksum mismatch for blocks range %d-%d: "

bmaptool: ERROR: checksum mismatch for blocks range 0-0: calculated b5bb9d8014a0f9b1d61e21e796d78dccdf1352f23cd32812f4850b878ae4944c, should be 7d865e959b2466918c9863afca942d0fb89d7c9ac0c99bafc3749504ded97730 (image file foo.img)

This happens because instead of looking for a bmap file by taking the basename of the image file and adding the bmap extension, bmaptool first tries the original filename (not its basename) and adds the bmap extension to that.

Where is the error? In the documentation or in the implementation?

It becomes even more confusing if the file has multiple extensions which is common when compressing the disk image. For example, if the image file is called foo.img.gz, then bmaptool will look for bmap files in this order:

1. foo.img.gz.bmap
2. foo.img.bmap
3. foo.bmap

Is this intentional and should the documentation be updated or should the implementation be changed to match the documentation?

Thanks!

[josch]

Hi, I'd like to contribute a pull request fixing this issue but I'd need to know what the intended behaviour is first. :)

[josch]

In the absence of any maintainer input, and assuming that the code is correct and the docs are not, I filed #35 to fix the docs.