Given a directory path (or NSURL) I need to get the total number of files/documents in that directory - recursively - as fast and light as possible. I don't need to list the files, and not filter them. All the APIs I found so far (NSFileManger, NSURL, NSDirectoryEnumerator) collect too much information, and those who are recursive - are aggregating the whole hierarchy before returning. If applied to large directory - this both implies a high CPU peak and slow action, and a huge memory impact - even if transient. My question: What API is best to use to accomplish this count, must I scan recursively the hierarchy? Is there a "lower level" API I could use that is below NSFileManager that provides better performance? One time in the middle-ages, I used old MacOS 8 (before MacOS X) file-system APIs that were immensely fast and allowed doing this without aggregating anything. I write my code in Objective-C, using latest Xcode and MacOS and of course ARC.

My App is a rather small menu-bar status-item app with 2 informational windows. It does NOT make use of ANY of the APIs mentioned here: https://developer.apple.com/forums/thread/663874 that are bound to need "Local Network" hence trigger TCC dialog. Yet - on first run of the app, the dialog pops. App is Obj-C, and the only APIs used are Notification-Center (for scheduling local notifications to the user), XPC connections and calls to other (our) apps for gathering that information, plus normal AppKit windowing (Controls, Text-fields, etc.) nothing else. Obviously SOMETHING I do causes the thing - and I know for sure this app DOES NOT NEED access to the local network - only I do not know how to identify the specific API I need to avoid using (or change the way I'm using) Are there any specific system logs to watch for? Is there any official set of APIs that will trigger the dialog? Provided that I cannot avoid this - could this permission be granted via MDM profile payload? Our product comes with

I am experiencing strange crashes in my (ObjC) code, that insinuate some memory corruption (mostly running SHA256 decryption for file data in my code there's a // return object that was stored in encrypted file - (id) objectFromEncryptedFile:(NSString *)filePath { // read MYCrypto object that includes encrypted object of any class MYCrypto *encData = [NSKeyedUnarchiver unarchiveObjectWithFile:filePath]; // decrypt, unarchive and return return [encData objectFromEncryptedData:encData.data]; } That seems to be called from different queues that are not synchronized. It came to me that maybe NSKeyedUnarchiver is not "thread safe" and maybe unarchiveObjectWithFile is not reentrant? Couldn't find anything in the normal documentation, but most of the old docs are no longer searchable. Can someone shed light on this?

I have several processes maintaining NSXPConnection to an XPC service. The connections are bi-directional. Each side service and clients) of the connection exports an object, and an XPCInterface. The @protocols are different - to the service, and from the service to clients. So long as all the "clients" fully implement their "call-back" @protocol, there's no problem. All works fine. However - If a client does NOT implement a method in the "call back protocol", or completely neglects to export an object, or interface - and the service attempts to call back using the nonexistent method -- the XPC connection invalidates immediately. So far - expected behaviour. However, if I want the service to behave to the client a little like a "delegate" style -- and check first whether the client "respondsToSelector" or even - supports an interface BEFORE calling it, then this doesn't work. When my XPC service tries the following on a client connection: if (xpcConnection.remoteObjectInterface == nil) os_log_error(myXPCLog, "client has no remote interface); the condition is never met - i.e. the "remoteObjectInterface is never nil even when the client does NOT configure its NSXPCConnection with any incoming NSXPCInterface, and does not set an "exportedObject" Furthermore, the next check: if ([proxy respondsToSelector:@selector(downloadFiltersForCustomer:withReply:)]) { } will not only fail - but will drop the connection. The client side gets the invalidation with the following error: <NSXPCConnection: 0x600000b20000> connection to service with pid 2477 named com.proofpoint.ecd: received an undecodable message for proxy 1 (no exported object to receive message). Dropping message. I guess the "undecidable message" is the respondsToSelector - because the code doesn't get to attempt anything else afterwards, the connection drops. Is there a way to do this check "quietly", or suffering only "interruption", but without losing the connection,

I recently upgraded a line of code in my Endpoint-Security client, to remove a deprecation warning: for (NSString *mutePath in ignoredBinaryPaths) { //(old) res = es_mute_path_literal(self.esClient, [mutePath UTF8String]); res = es_mute_path(self.esClient, [mutePath UTF8String], ES_MUTE_PATH_TYPE_TARGET_LITERAL); if (res!=ES_RETURN_SUCCESS) os_log_error(setupLog, "Failed to white-list binary:%{public}@ error:%{errno}d", mutePath, errno); } However, after this change, I started receiving tons of ES event messages, for AUTH_OPEN and AUTH_CREATE and many others, from processes/executables I explicitly and successfully muted! Since ES is so performance sensitive - I got worried. Inspecting better the new API I found incoherent documentation and even misleading and contradicting definitions. But the ES headers say differently!!! /** * @brief Suppress all events matching a path. * * @param client The es_client_t for which the path will be muted. * @param path The path to mute. * @param type Describes the type of the `path` parameter. * * @return es_return_t A value indicating whether or not the path was successfully muted. * * @note Path-based muting applies to the real and potentially firmlinked path * of a file as seen by VFS, and as available from fcntl(2) F_GETPATH. * No special provisions are made for files with multiple ("hard") links, * or for symbolic links. * In particular, when using inverted target path muting to monitor a * particular path for writing, you will need to check if the file(s) of * interest are also reachable via additional hard links outside of the * paths you are observing. * * @see es_mute_path_events * @discussion When using the path types ES_MUTE_PATH_TYPE_TARGET_PREFIX and ES_MUTE_PATH_TYPE_TARGET_LITERAL Not all events are * supported. Furthermore the interpretation of target path is contextual. For events with more than one target path (such as * exchangedata) the behavior depends on the mute inversion state Under normal muting the event is suppressed only if ALL paths * are muted When target path muting is inverted the event is selected if ANY target path is muted For example a rename will be * suppressed if and only if both the source path and destination path are muted. Supported events are listed below. For each * event the target path is defined as: * * EXEC: The file being executed * OPEN: The file being opened * MMAP: The file being memory mapped * RENAME: Both the source and destination path. * SIGNAL: The path of the process being signalled * UNLINK: The file being unlinked * CLOSE: The file being closed * CREATE: The path to the file that will be created or replaced * GET_TASK: The path of the process for which the task port is being retrieved * LINK: Both the source and destination path * SETATTRLIST: The file for which the attributes are being set * SETEXTATTR: The file for which the extended attributes are being set * SETFLAGS: The file for which flags are being set * SETMODE: The file for which the mode is being set * SETOWNER: The file for which the owner is being set * WRITE: The file being written to * READLINK: The symbolic link being resolved * TRUNCATE: The file being truncated * CHDIR: The new working directory * GETATTRLIST: The file for which the attribute list is being retrieved * STAT: The file for which the stat is being retrieved * ACCESS: The file for which access is being tested * CHROOT: The file which will become the new root * UTIMES: The file for which times are being set * CLONE: Both the source file and target path * FCNTL: The file under file control * GETEXTATTR The file for which extended attributes are being retrieved * LISTEXTATTR The file for which extended attributes are being listed * READDIR The directory for whose contents will be read * DELETEEXTATTR The file for which extended attribues will be deleted * DUP: The file being duplicated * UIPC_BIND: The path to the unix socket that will be created * UIPC_CONNECT: The file that the unix socket being connected is bound to * EXCHANGEDATA: The path of both file1 and file2 * SETACL: The file for which ACLs are being set * PROC_CHECK: The path of the process against which access is being checked * SEARCHFS: The path of the volume which will be searched * PROC_SUSPEND_RESUME: The path of the process being suspended or resumed * GET_TASK_NAME: The path of the process for which the task name port will be retrieved * TRACE: The path of the process that will be attached to * REMOTE_THREAD_CREATE: The path of the process in which the new thread is created * GET_TASK_READ: The path of the process for which the task read port will be retrieved * GET_TASK_INSPECT: The path of the process for which the task inspect port will be retrieved * COPYFILE: The path to the source file and the path to either the new file to be created or the existing file to be overwritten */ So the behavior completely changed, you can no longer specify executables (via their binary path) from which you do NOT want any events Muting effectively became reactive, not proactive. Why this change is not documented with the deprecation? Why no alternative is suggested? why find this only because it broke my software tool behavior and performance? And last: For how long can I rely on the old, deprecated APIs, should I choose to revert my change instead of devising a whole new mechanism for muting un-interesting