From: David Zeuthen Date: Tue, 25 Oct 2011 20:42:09 +0000 (-0400) Subject: Handle the case where blkid(8) detects both a filesystem and a partition table X-Git-Tag: upstream/2.1.2~443 X-Git-Url: http://review.tizen.org/git/?a=commitdiff_plain;h=6cf7e7c87cbe7695ca4e4cd261f20262625367fe;p=platform%2Fupstream%2Fudisks2.git Handle the case where blkid(8) detects both a filesystem and a partition table The F15 x86_64 live cd is both an ISO filesystem and a partition table, presumably on purpose: # blkid -o udev -p ~davidz/Downloads/Fedora-15-x86_64-Live-Desktop.iso ID_FS_LABEL=Fedora-15-x86_64-Live-Desktop.is ID_FS_LABEL_ENC=Fedora-15-x86_64-Live-Desktop.is ID_FS_TYPE=iso9660 ID_FS_USAGE=filesystem ID_PART_TABLE_TYPE=dos If just used on an optical disc this presents no problem per se because the kernel does not create partitions. However, if you dd the image to a USB stick, the kernel will in fact recognize the partition table and create a partition for it: # blkid -o udev -p /dev/sdb ID_FS_LABEL=Fedora-15-x86_64-Live-Desktop.is ID_FS_LABEL_ENC=Fedora-15-x86_64-Live-Desktop.is ID_FS_TYPE=iso9660 ID_FS_USAGE=filesystem ID_PART_TABLE_TYPE=dos # blkid -o udev -p /dev/sdb1 ID_FS_LABEL=Fedora-15-x86_64-Live-Desktop.is ID_FS_LABEL_ENC=Fedora-15-x86_64-Live-Desktop.is ID_FS_TYPE=iso9660 ID_FS_USAGE=filesystem ID_PART_TABLE_TYPE=dos ID_PART_ENTRY_SCHEME=dos ID_PART_ENTRY_TYPE=0x17 ID_PART_ENTRY_FLAGS=0x80 ID_PART_ENTRY_NUMBER=1 ID_PART_ENTRY_OFFSET=0 ID_PART_ENTRY_SIZE=1161216 ID_PART_ENTRY_DISK=8:16 There is nothing, per se, wrong with this ... except that applications (such as udisks and GNOME sitting on top) need to be careful and not e.g. offer *two icons* for the iso9660 filesystem (one for sdb and one for sdb1). The fix is fortunately simple - we only allow a 'disk' block device to be a PartitionTable or a Filesystem and not both at the same time. The way we do this is to look at whether the kernel has already partitioned the device or not (and this works only because the kernel partiitoner guarantees that partition kobjects are created prior to announcing the 'disk' block device). Also stress in the docs that applications shouldn't be looking at IdUsage or IdType (a direct copy of whatever blkid(8) puts in the udev database) and that they instead should be looking at what D-Bus interfaces are implemented. Signed-off-by: David Zeuthen --- diff --git a/data/org.freedesktop.UDisks2.xml b/data/org.freedesktop.UDisks2.xml index 2b34f7e..6b96ae8 100644 --- a/data/org.freedesktop.UDisks2.xml +++ b/data/org.freedesktop.UDisks2.xml @@ -500,8 +500,17 @@ necessarily mean the device contains no structured data; it only means that no signature known to the probing code was detected. + + Applications should not rely on the value in this or the + #org.freedesktop.UDisks2.Block:IdType property - instead, + applications should check for whether the object in question + implements interfaces such as + e.g. #org.freedesktop.UDisks2.Filesystem, + #org.freedesktop.UDisks2.Swapspace or + #org.freedesktop.UDisks2.Encrypted. --> + +