Just to check if a file under a given URL is dataless or not, you can have a look at URLUbiquitousItemDownloadingStatus. Whether you can use this inside File Provider extension process or not, or how to know which URLs to check - that's a separate question I can't answer.

We found the cause - this happens when extension returns content of different size (even larger) than the range for fetchPartialContents. In our case it happened quite rarely and the content was always larger - which is quite surprising looking at the docs in NSFileProviderPartialContentFetching.h: On-disk layout: (...) The file contents outside of the fetched range are ignored by the system. (...) For instance, if the fetchedRange is {offset:0x100000, length:0x1000} (...) The ranges {0, 0x100000}, and {0x101000, EOF} can be anything including sparse ranges. So actually in this example, if I understand correctly what fetched range refers to, if EOF > 0x101000 (i.e. fetched data extends beyond the range), the issue reproduces. FWIW leaving some more details in case it's useful for someone reading this: Analyzing sysdiagnose logs was quite helpful - in logs from log show --archive system_logs.logarchive we noticed this extent length is not as expected (524488 != 524288) and based on that quickly found that we are actually returning 524488 bytes of data instead of 524288. The issue can be quite easily simulated / reproduced with FruitBasket by applying attached patch. Steps to reproduce create big enough file (mkfile 10m test.txt) remove download read some first bytes (head -c 4096 test.txt) read fails and the file is now permanently broken, cannot be downloaded invalid-argument.txt