copyfile why does it take so much longer for a Sandboxed app to finish?

So, when copying a file or directory (particularly to an external drive) i've noticed there is a huge difference in performance between a sandboxed and non-sandboxed app.


When copying a directory and the app isn't sandboxed, the copy finishes in reasonably fast (like a minute..didn't time it though). When sandboxed, copying is still going on...very slowly, it's been like 20 minutes. Still isn't finished. For what it's worth, when using NSFileManager API to copy I notice big performance hit too when the app is sandboxed (not sure if NSFileManager is just wrapping copyfile anyway).


Anyone know why and if there is a workaround?

Replies

Yeah.....well...copying the folder was still going on after like a half hour in the sandboxed version of the app. Finally gave up. Just tested again..the non-sandboxed version of the app copied the entire directory to the external drive in like 60 seconds.


Basically this is the difference between acceptable and unacceptable performance as far as my customers are concerned. Not sure if there's really anything I can do about it though 😟 sadly

You should look in the console for any sandbox violations. A sandbox violation triggers a bunch of logging, so if you hit a lot of them then things can slow to a crawl.

Share and Enjoy

Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware

let myEmail = "eskimo" + "1" + "@apple.com"

Yea was looking for that earlier. Didn't find anything that helped me figure out a workaround sadly.


Sandbox: mdworker(22047) deny(1) mach-lookup com.apple.FileCoordination

Sandbox: mdworker(22047) deny(1) mach-lookup com.apple.security.syspolicy

Sandbox: bluetoothd(149) deny(1) mach-lookup com.apple.server.bluetooth

error 16:37:32.780627-0400 kernel Sandbox: diskarbitrationd(121) System Policy: deny(1) file-read-data /dev/rdisk1s3

Sandbox: bluetoothd(149) deny(1) mach-lookup com.apple.server.bluetooth

Sandbox: mds(119) deny(1) network-outbound /private/var/run/mDNSResponder


I do see a good amount of these log out:


AFP_VFS afpfs_DoReconnect: Restoring session /Volumes/TheVolumeNameHere..

Did you find the solution?
In my case NSFileManager || copyfile is too slow in "Non-sandbox" application and not tested for the sandbox application.
I did not find a solution. I filed a Feedback and Apple typically asked for a sysdiagnose, which I do not have time to provide right now. Should be easy for them to reproduce by trying to copy a directory with lot of contents inside of it. But I don't have time to put together a sample project for them right now.

Sorry for not replying. I don't get e-mail notifications when people reply to threads I participated in on these new forums. So the only way I know if people are talking is to manually check the forum post periodically which is basically a nightmare.