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. It’s certainly due to some changes in DesktopServicesHelper on macOS Tahoe which triggers file deletion if it 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. Interesting. I spent some time looking at our code today and, while I wasn't able to find the specific change, there were a number of operation timeouts added to the copy architecture as part of resolving a number of hangs and other issues. None of them exactly match what you're describing, but the Finder's copy implementation is sufficiently complex that it's likely that I simply missed something. A few different comments: I should have asked this earlier, but what's the auth event you’re actually blocking and are you sure it's something you SHOULD be blocking? Nota
Topic:
App & System Services
SubTopic:
Core OS
Tags: