{"id":39355,"date":"2023-05-11T14:31:33","date_gmt":"2023-05-11T18:31:33","guid":{"rendered":"https:\/\/mjtsai.com\/blog\/?p=39355"},"modified":"2023-08-10T10:24:39","modified_gmt":"2023-08-10T14:24:39","slug":"getting-ready-for-dataless-files","status":"publish","type":"post","link":"https:\/\/mjtsai.com\/blog\/2023\/05\/11\/getting-ready-for-dataless-files\/","title":{"rendered":"Getting Ready for Dataless Files"},"content":{"rendered":"

TN3150<\/a>:<\/p>\n

In a modern file system, a file’s content may not be available locally on the device. A file that contains only metadata is known as a dataless<\/em> file. The file’s content typically resides on a remote server and is available to people or apps, transparently, when they access the file.<\/p>

[…]<\/p>

The system, or a person using the device, can make dataless files whenever they determine it’s appropriate, and your app needs to be ready to handle them. Specifically, avoid unnecessarily materializing dataless files and, when your app requires access to a file’s contents, perform that work asynchronously off the main thread.<\/p>

[…]<\/p>

UIDocument<\/code> and NSDocument<\/code> automatically access the file system in a coordinated and asynchronous manner.<\/p>

[…]<\/p>

If your app or framework uses low-level POSIX APIs to access the file system and you’re unable to migrate to the preferred methods, consider the following two options[…] Be aware that stat<\/code> and getattrlist<\/code> both trigger the materialization of any intermediate folders in the file’s path, if they themselves are dataless.<\/p><\/blockquote>\n

I find this rather confusing. On macOS, it seems like nearly any file could potentially<\/em> be dataless. It’s less likely for files in Library<\/tt> but probably possible via symlinking. Even an action as simple as checking whether a file exists can now take an unexpectedly long amount of time. This breaks many longstanding assumptions.<\/p>\n

If your app deals with user-created files, I guess the best practice is to do everything asynchronously and using file coordination. Without coordination—at least on older systems—you can run into the opposite problem: instead of accessing an evicted file being slow, it might stay unmaterialized. So you need to use the special APIs even if you already have your file code on a background thread.<\/p>\n

But the NSFileCoordinator<\/code> APIs are awkward, error-prone, and slow, and they infect your entire codebase. Hopefully you aren’t relying on any cross-platform code that’s not aware of them. And even with Apple-specific code, they make it hard to reuse the same code for working with folders that may or may not contain dataless files.<\/p>\n

It all feels shoehorned in, like with the security scope URL APIs. Most APIs don’t do the right thing automatically, so you have to wrap uses of them. (But then some other APIs may secretly use coordination<\/a> so you have to not<\/em> use it yourself in order to avoid deadlocks<\/a>.) Any file-related code could potentially need special handling, but there’s no way to make sure that you didn’t miss a spot somewhere. But then, once you’ve done this, your code is much harder to read and much slower for the common<\/em> case of regular locally stored files.<\/p>\n\n

Previously:<\/p>\n