DAPLink
DAPLink copied to clipboard
ARMmbed
macOS 15 Sequoia USB drive name shows as `NO NAME`
This has been reported with the micro:bit V2.00 and V2.21, using DAPLink 0255 to 0258.
This problem is not present for micro:bit V1, where the USB drive name is still MICROBIT, tested with DAPLink 0249, 0254 and 0258.
The V1 device name contains 3 spaces at the end MICROBIT (11 characters in total):
https://github.com/ARMmbed/DAPLink/blob/82dc31d09456710ad0610db5b0ee2a73282f6acc/source/board/microbit.c#L78
And V2 does not have the spaces present: https://github.com/ARMmbed/DAPLink/blob/82dc31d09456710ad0610db5b0ee2a73282f6acc/source/board/microbitv2/microbitv2.c#L475
Switching the strings between the V1 and V2, and testing the builds in macOS and we can confirm that the issue seems to be related to the spaces.
There are a few more cases of other ports where spaces have been added until the 11th character (and some where a shorter than 11 characters name doesn't have spaces either), and haven't found a drive name with more than 11 characters. So maybe the standard specifies it needs to be 11 characters exactly? A bit odd that this has never been an issue anywhere else before.
The structure is 11 bytes long. The difference between the two is that if you dont pad with spaces you will end up with \0 values in the name. I guess Sequoia is more defensive on how it handles this.
Thanks Mathias! I wrongly assumed perhaps the volume name was null terminated anyway, but yeah, it's just 11 characters and no need to null terminate it. Still a bit weird that this has never been a problem anywhere in the past, we should update the device names in DAPLink, but this is could likely to be a problem with other non-daplink devices as well, it'd be good if Apple reverted it as well.
This FAT specification doc from Microsoft doesn't explicitly indicate not to use null characters, but it looks like even the default "NO NAME " contains extra spaces:
https://academy.cba.mit.edu/classes/networking_communications/SD/FAT.pdf