Our backup app (Arq) is encountering random errors for some users on macOS Sequoia. The method [NSFileManager contentsOfDirectoryAtPath:error:] returns nil with an NSError domain NSCocoaErrorDomain, code 256 ("NSFileReadUnknownError"). The NSError's NSUnderlyingError key is an NSError with domain NSPOSIXErrorDomain and code 4 (EINTR). Sometimes waiting and retrying works fine; sometimes 5 retries still fail. For some users it happens on different directories each time they try to back up. What is causing this? Are we supposed to use a different API to get directory contents these days?

Our backup app runs as a LaunchDaemon, has APFS-snapshot entitlement, and attempts to read and back up dataless files/directories by calling setiopolicy_np(IOPOL_TYPE_VFS_MATERIALIZE_DATALESS_FILES, IOPOL_SCOPE_THREAD, IOPOL_MATERIALIZE_DATALESS_FILES_ON) before reading files/directories. This worked for a while but lately has been producing many ETIMEDOUT errors for our users, especially for iCloud files but sometimes for FileProvider files e.g. Dropbox. We've attempted to wait up to 5 minutes and retry, but the ETIMEDOUT error persists. In many cases the errors stop hours or days later. Some users report that clicking the icon in the Finder and telling the Finder to "download" the file/directory (for iCloud files) successfully downloads the file data, and then backups proceed without error. Why is the user able to easily materialize dataless files but our app isn't? What is the correct approach for backing up these files/directories? What APIs can we use to determine the actual issue with a given dataless file/directory that's giving us a read error?