I am having trouble with the issue where the media name and storage information name, which matched in MacOS 14 and earlier, are now inconsistent with the volume label and "NO NAME" in MacOS 15.
First off, if you haven't already, please file a bug report on this issue and post the number back here.
The problem is that while changing the name on macos 15 will temporarily unify the names, if you overwrite them on Windows they revert to "NO NAME".
Is any of your software actually involved with this on Windows? Or is this happening with a standard Windows install without any other software involved?
At first I thought it was reflecting BS_VolLab in the boot sector, but that doesn't seem to be the case.
There are a lot of intermediate layers involved which, unfortunately, makes it hard for me to say exactly what would happened. However, what I can do is explain how this can happen and suggest how I'd investigate it.
SO, the underlying issue here is that there are actually two different mechanisms at work here:
-
Many different API can retrieve the volume name of a mounted volume, but all of them eventually go back to the "f_mntfromname" of the "statfs" data structure. Note that this only works for mounted volumes, since statfs can only be called on a mount target (either by path or file descriptor).
-
DiskArbitration has a separate code path with retrieves the "volume name" using a "probe" operation implemented by every file system on the system, as part of the broader architecture the system uses to identify the volume format of new volumes. Importantly, "NO NAME" is NOT actually a valid name, but is the string DiskArb returns when the name problem return "NULL" on an msdos volume (all other volume types fallback to "Untitled").
With that context, I believe that happened is that #2 failed to retrieve a valid name (so it returned "NO NAME") while #1 returned MOFMOF, which was determined when the volume was mounted. WHY it returned NULL is something I can't really answer, but if I had to guess then the first thing I would look at is exactly how the names involved were encoded. exFAT names are UTF-16 encoded while macOS uses UTF-8 for "everything" and that encoding change is the most "obvious" place that could create this kind of failure with minimal risk of broader corruption.
That leads to here:
At first I thought it was reflecting BS_VolLab in the boot sector, but that doesn't seem to be the case.
I'm not sure where the information actually comes from, but my recommendation for how to investigate this would be the following:
-
Start with the smallest volume/device you can find, ideally zero'ing the entire device before you start. Zero'ing the device makes it easier to look at the raw data, since it ensure that the you're only looking at "real" data, not old blocks that aren't in use but haven't been over written.
-
Start with a volume that returns "NO NAME" and capture the raw block contents of the entire disk.
-
Correct the issue with the Finder and capture the raw block contents of the entire disk (again).
-
Compare the captures of "2" and "3" to find the difference.
-
Once you've determined what's different, take that "back" to the original file system specification to determine what's actually going wrong.
Note that this is just the "basic" approach, with many other variations being possible. For example, what I would actually do is use DiskUtility to create a disk image of the entire device (DiskUtility.app-> File-> New Image-> Image From "<source device>") at #2, duplicate that image in the Finder, then correct the issue on the image using the Finder. That gives you two images (failing and working) which you can then compare at "at will" without need to mess around with physical devices.
__
Kevin Elliott
DTS Engineer, CoreOS/Hardware
