The curious case of FileManager’s 512 error on iOS

Daniel Galasko
Over Engineering
Published in
3 min readJan 12, 2021
A fellow developer, trying to debug a complex problem. Credit: Unsplash

For many years of having our App in the App Store, a particular bug alluded us most mischievously. Various reports would come in that distilled down to a simple problem: Customers with plenty of space on their device could not make any changes to the file system. Some of these bugs manifested as follows:

  1. Unable to download new files.
  2. Unable to upload new files.
  3. Unable to duplicate a file.
  4. Unable to save changes to an existing file.
  5. Unable to delete files.

When we received these reports, we were painfully unaware they were the same bug since they manifested in seemingly unrelated parts of the App. We captured device logs and searched the internet and still found ourselves unable to understand what was happening.

So, we filed a support ticket with Apple to get an engineer’s eyes on this.

After some productive back and forth and a user who could to help us that could replicate the issue, he led us down a path that helped us get the error in question. In this instance, we looked at why UIDocument would fail to save changes to an existing document. He instructued us to override the handleError API and log the outputs.

The following error message revealed itself:

"localizedDescription": "The operation couldn’t be completed.",
"domain":"NSCocoaErrorDomain",
"code":512

Our helper at Apple pointed us to an obscure post in the forums that said the following:

In a nutshell, there is an arbitrary limit set on items in the Caches and tmp directories, that limit is 1000. Meaning, for our longtime customers, when those folders got too big, everything stopped working 🤯. Furthermore, iOS was not automatically pruning these directories as one might expect.

Our first step was to ship a build that had a deeplink to clear Caches and tmp. We sent this to users that experienced the problem and voilà, it worked! 💃Taking this a step further, we decided to write a utility that pruned these folders on each app update. We watched our errors go down to zero in no time.

It is worth mentioning that some developers have reported that this seems to be a problem, mainly when creating entries in these folders where the filename is generated using UUID().uuidString. We definitely make use of this API but if it’s affecting you too, I hope this helped you on your journey.

🧠 Moral of the story

If you find your App failing to make any changes using FileManager, look at your error code and see if it matches 512 and you have a large Caches and tmp directory.

I hope this saves you the time it took us to get to the bottom of this so that you can get your customers back and running in no time.

--

--