We are seeing this behaviour even with mounted disk images. We will test with AFP server also. We are not seeing this behaviour when we copy using cp or mv terminal commands or any other application. Its certainly due to some changes in DesktopServicesHelper on macOS Tahoe which triggers file deletion if its takes more than 5 seconds to transfer. We have tried with less than 5 seconds like 4.5 sec or 4.9 seconds and it works as expected.

To add more context, Suppose user is copying file from one destination to a Network location. DesktopServicesHelper creates the file at destination and writes it. Now once the file is written, we start inspecting the content in any ES auth event received for the written file. If it took longer than 5 seconds to complete the file inspection (which is well below the deadline for auth event) then DesktopServicesHelper just deletes this file created at the destination. This we are observing in macOS Tahoe only. Ideally, DesktopServicesHelper should wait till ES event is responded before go ahead with deletion of the file.

Hi Kevin, Thanks for your response. We understand that Endpoint Security authorization deadlines represent upper bounds and that ES clients are expected to respond as quickly as possible. We are not suggesting that Finder or DesktopServicesHelper bypasses kauth or Endpoint Security authorization. We attempt to perform file inspection as early as possible for files leaving the user’s machine; however, in real-world scenarios, inspection time can occasionally exceed a few seconds. Our concern is with the observed behavior where DesktopServicesHelper appears to proceed with unlinking the source file before the ES authorization event associated with the operation has received a response.

After following the steps and discussions for the same problem raised by the other users and system restart it got fixed. So not sure about the exact steps

It was permission related issue on the app.

Thanks Eskimo for reply and suggestions. Can you help me to understand Why the application icon is shown with blocked mark in finder? This blocked mark on application icon is removed when the application permission changes.

Yes, the daemon uses restricted entitlement and hence needs a provisioning profile. My issue is on step 4: User can navigate to the directory which contains daemon app. Here, in finder, App logo is shown with blocked symbol on it which basically means unsupported. When the user tries to launch it then it throws error as app unsupported.

Yes, I get this message when I try to launch the app through finder double click. My main concern is that Finder shows this app as unsupported i.e. the logo of the app comes with blocked mark on it.

Thanks for reply. No, its not GUI app but its and kind of System Extension bundled as application. It does not display UI. This app is loaded as a launch deamon using a plist. The app is launched in root context.