Comment 6 for bug 1469143

In addition to not handling long paths, kpartx also fails to handle relative paths correctly. Here's an example:

for d in 1 2
do
  mkdir $d && (
    cd $d &&
    dd if=/dev/zero of=disk.img seek=8k count=1 2> /dev/null &&
    (echo n;echo;echo;echo;echo;echo w) | fdisk disk.img >/dev/null &&
    kpartx -av disk.img
  )
done

Expected result:
add map loop1p1 (254:0): 0 6145 linear /dev/loop0 2048
add map loop2p1 (254:1): 0 6145 linear /dev/loop1 2048

Actual result:
add map loop1p1 (254:0): 0 6145 linear /dev/loop0 2048
add map loop1p1 (254:0): 0 6145 linear /dev/loop0 2048

Currently kpartx end up modifying the existing binding instead of creating a new one.

Both the long path problem and the relative path problem are caused by kpartx trying to use the binding name to store the image file path and assuming that the name would uniquely identify a binding.

The correct way is to use the device and inode numbers of the image files to identify which loop mount is attached to which image file. I have attached a patch which does exactly this.