Hi Glenn! On 1/5/22 11:23, John Paul Adrian Glaubitz wrote: > Thanks for debugging and reporting this. I will have a look at this bug and > fix it hopefully soon. Also, thanks for fixing so many issues in GRUB, I'm > on the GRUB mailing list as well and I'm seeing your regular influx of > patches there!
So, I just had a look at the code again and compared it with the original code from the last version of the diskdev_cmds which supported legacy HFS [1]. The original code contains an embedded function to map UTF-8 into Mac encoding, search for "Map UTF-8 input into a Mac encoding.". I didn't reimplement that code back then because it uses some string code from Apple's CoreFoundation libraries. I assumed no one would bother if we just hardwire the volume label to "untitled" and moved on. However, since you now reported this bug, I think it's reasonable to fix this issue and I think it should be possible with the help of the sources of version 332.25-11. Looking at the corresponding patch [2], you can see that the patch implements a similar approach of what you suggested, see: + mdbp->drVN[0] = strlen(defaults->volumeName); + bcopy(defaults->volumeName,&mdbp->drVN[1],mdbp->drVN[0]); I'll think a bit over it to decide what approach we use. Reimplementing Apple's code as close as possible without using the CoreFoundation stuff would be my preferred solution. Maybe you have a suggestion on how to reimplement Apple's UTF-8-to-Mac conversion code from [1]. Adrian > [1] > https://opensource.apple.com/source/diskdev_cmds/diskdev_cmds-491/newfs_hfs.tproj/makehfs.c.auto.html > [2] > https://sources.debian.org/src/hfsprogs/332.25-11/debian/patches/0002-Add-exclude-Darwin-specific-code.patch/#L993 -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - [email protected] `. `' Freie Universitaet Berlin - [email protected] `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
