Package: udisks2 / 2.9.2-2

Metadata

Package Version Patches format
udisks2 2.9.2-2 3.0 (quilt)

Patch series

view the series file
Patch File delta Description
udisksclient Make get_block_for_drive deterministic.patch | (download)

udisks/udisksclient.c | 15 15 + 0 - 0 !
1 file changed, 15 insertions(+)

 udisksclient: make get_block_for_drive deterministic

While any given Block object has at most one corresponding Drive, many
Block objects may share the same Drive. One example is eMMC devices
which provide a block device for the main data area (e.g. /dev/mmcblk0)
as well as additional logical block devices for device partitions (e.g.
/dev/mmcblk0boot0 and /dev/mmcblk0boot1).

This behaviour was introduced in #834 to resolve issue #619 that these
device partitions caused a phantom additional Drive object to be
exposed. On that issue, I wrote:

> I believe that Block.Drive on the boot partitions should point to the
> same data area as the main data area (and its logical partitions);
> udisks_client_get_block_for_drive() on the drive should return
> /org/freedesktop/UDisks2/block_devices/mmcblk0.

The first part is now true, but as described on #879 the second part is
not true. It is now non-deterministic which Block will be returned,
based only on the order of objects returned by
g_dbus_object_manager_get_objects().

Make the return value of udisks_client_get_block_for_drive()
deterministic by sorting the list of candidate Block objects by their
device path in lexicographic order. Since (e.g.) /dev/mmcblk0 sorts
before /dev/mmcblk0boot0, this has the desirable side-effect that
calling udisks_client_get_block_for_drive() on an eMMC Drive returns the
'real' Block for the main data area.

Fixes #879.

(cherry picked from commit 5d0ac7ebefb8b7aad73871936f5011545cc66344)