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?
Are we supposed to use a different API to get directory contents these days?
Well yes, but that’s unrelated to this issue.
In general, I recommend that you use the URL-based routines — in this case that means contentsOfDirectory(at:includingPropertiesForKeys:options:) — because they allow you to get the items and their properties in one go. This can be radically more efficient, especially on high-latency volumes.
However, I doubt that’ll affect this issue. EINTR errors are a fact of life on Unix-y systems and in most cases your response should be to simply retry. I’ve talked about this many times before, but I used your question as an excuse to write it up properly. See Understanding `EINTR`.
I think you could make a reasonable case that Foundation should be retrying for you. If you want to do that, file a bug about this. And if you do file a bug, please post your bug number, just for the record.
Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"