Comment 13 for bug 536670

(In reply to comment #7)
> So, both the kernel code and blkid look surprisingly similar (what a
> coincidence :-P). I also checked the MBR spec [1], and if we allow 0
> offset/type partitions for empty partitions we can't indeed reliably detect an
> MSDOS partition table by itself, we have to check whether it is a valid FAT
> header (which has a much more rigid structure), and if we don't find one,
> assume that we have an MBR.
>
> Now, I see two possibilities:
>
> 1) We can copy the FAT detection logic from blkid (which is a tad more rigid
> than the kernel's)
>
> 2) We can assume that blkid is reliable (I don't see much evidence that it
> isn't), and skip partition probing if we already have a fs:
>
> ENV{ID_FS_TYPE}=="", IMPORT{program}="udisks-part-id $tempnode"
>
> (2) is essentially the same logic as (1) but avoids the overhead of calling
> part-id if we already know that there's a file system. It's also one step
> closer to getting rid of part-id in favor of a blkid based partition probing.
>
> I verified that this rule brings back automounting, and the automatic tests are
> happy again as well.
>
> So I'd favor (2), but if you see a reason to always call part-id, I can also
> work on (1).

Let's just go for (2) - seems simpler. Thanks.

>
> [1] http://en.wikipedia.org/wiki/Master_boot_record
>