Hi Adrian! This dropped off my radar, but I'm thinking about this issue again.
On Tue, 29 Mar 2022 19:15:29 +0200 John Paul Adrian Glaubitz <[email protected]> wrote: > 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. Based on how the GRUB tests use the -v argument, I don't think we need to do any re-encoding. The GRUB test uses recode to convert UTF8 to macroman and uses that as the argument. > 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 haven't really looked at the code, but I imagine it should be fairly easy to just copy the argument to -v into mdbp->drVN[1]. > 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]. If we really needed to probably using libiconv would be best. That's what recode does. But as I said above, I don't think we need to. Glenn > > 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 >
