On Sun, Aug 30, 2009 at 02:14:31PM +0200, Thomas Bächler wrote: >> It could be possible to reorder the detection algorithms to put LUKS >> ahead of the tests ext2/3/4 (and in the past when I was the sole >> maintainer of blkid I've done that sort of thing before), but really, >> depending on that kind of ordering is really a bad idea; it's better >> to fix a filesystem's utilities to do the right thing at mkfs time and >> if necessary to do any fixups in the filesystem's fsck utility. > > The order is still that way. However, blkid doesn't stop once it finds a > match: It does all probes, and when it finds more than one match, it > says nothing - only in debug mode it will inform you about the ambiguity. Hmm, well *that's* a change between the blkid that was in e2fsprogs and the version that was in util-linux-ng. In e2fsprogs' blkid, I stopped after I found the first match. As a result, the filesystems that had the most sophisticated (and thus less prone to false positives) were put *first*, and filesystems that had sloppy mkfs/mkswap/dmcrypt-setup programs that didn't zap the first and last 32k-64k of the partition to prevent false positives were placed later in the detection table. If the new blkid library in util-linux-ng searches the whole list and finds the *last* match, and it's using the same order of probes as in e2fsprogs' blkid, it means there will be a significant chance in behavior, and the danger is that there may be many more false positives. One could argue this is a good thing since it will force filesystems and swap/crypto/raid programs that have sloppy mkfs or other partition setup programs to be forced to fix it, but it will cause a large number of problems for users who used older versions of said sloppy partition setup/format utils. - Ted -- To unsubscribe from this list: send the line "unsubscribe util-linux-ng" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
