On Sun, Nov 30, 2008 at 23:23, Karel Zak <kzak@xxxxxxxxxx> wrote: > On Sun, Nov 30, 2008 at 07:30:56PM +0100, Kay Sievers wrote: >> the current hfs uuid's are the raw on-disk values, which do not match > > do you mean hfs uuid in my blkid branch? (The library is still > incomplete and my plan is check and document all UUID/LABEL/version > code to check compatibility between our libraries.) Sure, your stuff - which will be used to replace libvolume_id, if all works out as planned. :) >> the value of the original OS, or libvolume_id's values. Libvolume_id >> does the needed MD5 hashing, to translate them to the natively used >> 128 bit uuid: >> http://git.kernel.org/?p=linux/hotplug/udev.git;a=blob;f=extras/volume_id/lib/hfs.c;hb=HEAD#l146 > > I know about this problem -- "git pull; git log" is my good friend > and in my TODO list is "talk about strange HFS UUID with Kay" :-) > > That's unbelievable that Mac OS uses MD5 for UUIDs. (Is it really > true?) Yes, seems it's their idea to convert the 64 bit legacy stuff to the usual 128 bit DCE uuid, which is used in their (optional) fstab. If you want, I can create an image to test, along with the output of the native tools, which will show the MD5'd uuid? >> We should fix that. Want a patch for that, which includes a copy of md5: >> http://git.kernel.org/?p=linux/hotplug/udev.git;a=blob;f=extras/volume_id/lib/md5.c;hb=HEAD >> or do you possibly want to link against an external library? > > The util-linux-ng package already includes MD5 code (lib/md5.c), so > we can start with this local copy. (Although for example RH is > working on crypto stuff consolidation, so wee will see...) Sounds good. I don't really mind to link against a crypto lib in general - while it may still a bit scary for tools like mount to have too many dependencies. Mount may be essential in a rescue case, if something goes really wrong. For a start, we can use the in-tree copy of MD5 as a start, I guess? Thanks, Kay -- 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
