[BUG] Eject not working properly with APFS-formatted disk images [FIXED]

[JayB]

When you mount a DMG volume that's HFS-formatted, if your boot volume is on disk0 & disk 1, you get disk2:

Code: Select all

hdiutil attach /path/to/HFSimage.dmg
expected   CRC32 $9BAB5CEB
/dev/disk2          	GUID_partition_scheme
/dev/disk2s1        	Apple_HFS                      	/Volumes/MountPoint

If in Nimble Commander you hit CMD-E for eject, disk2 is "ejected", i.e. detached properly.

However, if you mount (attach) an APFS-formatted DMG volume, then you won't just get disk2, but disk2 & disk 3:

Code: Select all

hdiutil attach /path/to/APFSimage.dmg
Checksumming Protective Master Boot Record (MBR : 0)…
Protective Master Boot Record (MBR :: verified   CRC32 $95136301
Checksumming GPT Header (Primary GPT Header : 1)…
 GPT Header (Primary GPT Header : 1): verified   CRC32 $9D351286
Checksumming GPT Partition Data (Primary GPT Table : 2)…
GPT Partition Data (Primary GPT Tabl: verified   CRC32 $17EF87A9
Checksumming  (Apple_Free : 3)…
                    (Apple_Free : 3): verified   CRC32 $00000000
Checksumming disk image (Apple_APFS : 4)…
..........................................................................................................................................
         disk image (Apple_APFS : 4): verified   CRC32 $70DA5334
Checksumming  (Apple_Free : 5)…
                    (Apple_Free : 5): verified   CRC32 $00000000
Checksumming GPT Partition Data (Backup GPT Table : 6)…
GPT Partition Data (Backup GPT Table: verified   CRC32 $17EF87A9
Checksumming GPT Header (Backup GPT Header : 7)…
  GPT Header (Backup GPT Header : 7): verified   CRC32 $E6C60F89
verified   CRC32 $7F5845CF
/dev/disk2          	GUID_partition_scheme
/dev/disk2s1        	Apple_APFS
/dev/disk3          	EF57347C-0000-11AA-AA11-0030654
/dev/disk3s1        	41504653-0000-11AA-AA11-0030654	/Volumes/MountPoint

If in Nimble Commander you hit CMD-E for eject, only disk3, the actual data volume, is ejected (detached), but not the separate disk2 containing the partition map etc. Therefore disk3 is not really ejected at all, but simply unmounted, and can be remounted again using hdiutil or Disk Utility.

This needs to be corrected in a future update. A file manager should properly eject (detach) disk image media, and not let unmounted volumes & their auxiliary devices hanging around until reboot.

"Eject" should be a true "detach", and not an unmount, i.e. it should remove all devices associated with a disk image volume.

[mike]

I confirm the problem.
Looking for a solution, right now it's unclear where to get any additional data to find the parent disk image.
Any hints are welcome.

[JayB]

On the command line it's not a problem. If you have the disk number of an APFS volume, e.g. volume disk3s1, then the standard

Code: Select all

diskutil list disk3s1

will tell you that the volume is in an APFS container disk3. If you then execute

Code: Select all

diskutil apfs list disk3

it will reveal that the physical store for the APFS container is disk2s1, which is obviously on disk2. Then you can run diskutil eject on disk2, and the whole thing will be ejected, disks 2 & 3, the store, the volume & the container.

But is similarly simple in C++?

[mike]

I can't see any official API for getting this info.
Looks like the only way is to silently run diskutil, get its output and then parse it.
Oh well...

[JayB]

You should probably do that immediately after mount, right? Not at the moment the user gives the eject command, so the user won't notice any speed difference. (?)

But this would only be for disk images; for other media, you can't do a true "eject" anyway, unless it's a DVD etc. SSDs remain plugged-in, so in these cases the possibility to re-mount is actually a good thing.

[mike]

Nah, nothing guarantees that some volume wasn't mounted when NC was off.

[JayB]

Of course. You're right.

[mike]

Ok, I've implemented the fix, it will be available in next preview.

Although sandboxed versions (i.e. from MacAppStore) can't access "diskutil" to get this info, thus there's simply no way to reliably unmount&eject an APFS volume in these versions. Of course, Apple has all the infrastructure to access the layout data, but it's contained in a private framework and Apple will not allow into MAS any app which uses non-official APIs. Alas.