Error when unmounting after uploading to device in the SDK: OSStatus error -47

I am consistently getting the error Unmount: The operation couldn’t be completed. (OSStatus error -47.) (null) after using CMD+U to upload my game to the device from the Simulator. Side-loading with data disk mode works as normal. I'm on MacOS 12.1 Monterey and have already tried rebooting my computer, playdate, and SDK multiple times. Any suggestions? This wasn't happening a few days ago and I'm not sure what I could have changed.

-47 is file is busy error. Which is why the OS is not allowing you to unmount the disk. Are you connecting your device directly to your computer and not through a hub?

Yes, it's connected directly (USB-C to USB-C). For what it's worth, sometimes my computer is slow to recognize the Playdate as an external disk when I'm in data disk mode for sideloading. But if it doesn't work the first time, unplugging and trying again, or waiting a minute or so, will usually fix it. Maybe I have been ejecting the disk improperly? I either have been doing it directly in the Finder's sidebar, or by pressing A on the Playdate to exit data mode. Pressing A on the Playdate makes MacOS say the device wasn't ejected properly though.

At this point I'm beginning to think I've permanently corrupted my device somehow. Here is some more information and the sequence of events that I'm trying:

  1. Reboot Macbook and make sure nothing is open (no Finder or Simulator)
  2. Plug in the Playdate directly to my Macbook over USB-C
  3. Unlock Playdate
  4. Open Simulator and press CMD+U to upload game to device
  5. The only popup that occurs is the "Unmounting" loading bar, but only briefly for 1 second
  6. Receive OSStatus error -47 in the Simulator's console
  7. Playdate is currently at "sharing DATA segment as USB drive" screen
  8. I press A to boot back into the Playdate OS and Immediately a receive a "Disk Not Ejected Properly" notification from MacOS finder.

Here's the full output from the console:

echo off
target=DVT1
build=5f230668fc9b-1.11.1-release.136881-buildbot-20220519_192711
boot_build=5f230668fc9b-1.11.1-release.136881-buildbot
SDK=1.11.1
pdxversion=11000
serial#=PDU1-Y012987
cc=9.2.1 20191025 (release) [ARM/arm-9-branch revision 277599]
time and date set
Unmount: The operation couldn’t be completed. (OSStatus error -47.) (null)

I've also tried running the Mac Disk Utility "First Aid" feature on the Playdate. It can successfully unmount the Playdate. Here's the output showing that:

Running First Aid on “PLAYDATE” (disk2s1)

Checking file system and repairing if necessary and if possible.
Volume was successfully unmounted.
Performing fsck_msdos -y /dev/rdisk2s1
** /dev/rdisk2s1

** Phase 1 - Preparing FAT

** Phase 2 - Checking Directories

** Phase 3 - Checking for Orphan Clusters

9592 files, 2699344 KiB free (674836 clusters)

File system check exit code is 0.
Restoring the original state found as mounted.

Operation successful.

Finally, I've tried the steps above against multiple versions of the Simulator and with other PDX files too. Same result. I may try installing the SDK on a friend's Macbook next and try loading with that.

If you can eject the disk via the Finder, that'll be much better for the filesystem than forcing a reboot with the A button. If Finder says it can't eject it because there's a file open, you might be able to tell what file that is by running lsof | grep PLAYDATE in Terminal.app. I don't know what we'll do with that information, but.. it's information.

Good to know the Finder eject is better than the reboot command. The problem is I can't seem to identify anything that is holding a file open, in the Finder or otherwise. The Finder never has any issues ejecting the disk after the Simulator fails to unmount. At worst, the Finder takes a while to recognize the Playdate after it's plugged in, but that may not be related.

Do you know of any other places that I could check for processes holding on to a file? I feel like I must have done something wrong that caused this behavior.

Edit: I tried uploading to device on a different Macbook with a fresh SDK install and it worked fine. So something much be wonky on my Macbook...

I finally fixed this issue! Somehow an empty volume called PLAYDATE had been created but not removed under /Volumes/. Plugging the device in again was naming the new volume PLAYDATE 1, but the Simulator must have still been pointing to the empty volume PLAYDATE. The finder's UI didn't show any of this, in the sidebar the mounted volume still showed as "PLAYDATE" (without the 1). The original empty volume only showed in the terminal, not in the finder.

Here is what it looked like in terminal. Removing the bugged volume did the trick:

[user] /Volumes % ls -l            
total 0
lrwxr-xr-x  1 root  wheel   1 Jun  6 15:59 Macintosh HD -> /
d--x--x--x  3 root  wheel  96 May 31 14:18 PLAYDATE
[user] /Volumes % sudo ls PLAYDATE 
.Spotlight-V100
[user] /Volumes % rm -r PLAYDATE 

At some point the unmount procedure either in Finder or Simulator must have failed and created that phantom volume or I unplugged without ejecting it first. Either way I'm not sure what exactly caused it.

@madvogel I have had the "abandoned/duplicate mount point" issue you describe above, but with my Synology NAS Time Machine backup volume!