doronz88/pymobiledevice3 v11.1.5

on GitHub

Highlights

🐛 A backup no longer dies on DLMessagePurgeDiskSpace

When iOS decides the backup destination is too small it asks the host to make room, via DLMessagePurgeDiskSpace. That is a request, not a failure — Apple's own host (_DLPurgeDiskSpaceOnComputer in DeviceLink.framework) forwards CACHE_DELETE_VOLUME / CACHE_DELETE_AMOUNT / CACHE_DELETE_URGENCY_LIMIT to CacheDeletePurgeSpaceWithInfo(), replies with a DLMessageStatusResponse, and keeps serving the connection whether the purge worked or not.

pymobiledevice3 raised NotEnoughDiskSpaceError without answering the device at all. That tore the link down and replaced the device's own diagnosis with a guess, discarding the one useful number in the message: how many bytes it wants freed.

The handler now mirrors Apple's purge-failed path (status -1, "DLPurgeDiskSpace failed to purge", zero bytes reclaimed), logs what was asked for, and lets the loop continue — so the device gets to say what is actually wrong:

['DLMessageProcessMessage', {'ErrorCode': 105,
  'ErrorDescription': 'Insufficient free disk space on drive to back up (MBErrorDomain/105)'}]

Measured on an iPhone18,4 running iOS 26.6.1 by reporting a controlled figure for DLMessageGetFreeDiskSpace, CACHE_DELETE_AMOUNT is required - reported against a per-device constant:

To be clear about the scope: this does not make a refused backup succeed. When the device wants more room than the destination has, that is the device's call. What changes is that you see its reason and the exact byte figure it is demanding, instead of Not enough disk space from the host.

The figure reported for DLMessageGetFreeDiskSpace is now logged at debug level too — it is the number the device compares against, and it was missing from every bug report on this so far:

pymobiledevice3 -vv backup2 backup --full /path/to/backups

What's Changed

• 1efe69d device-link: answer DLMessagePurgeDiskSpace instead of aborting the backup (#1884) (@doronz88)

Full Changelog: v11.1.4...v11.1.5