Re: Performance issue on macOS 10.15 obtaining display name for ~/Desktop, ~/Documents, and ~/Downloads

[Gary L. Wade via Cocoa-dev]

Regardless of whatever workaround you find, I would second Rob’s suggestion to 
go ahead and file a bug with a sysdiagnose and/or spindump along with a sample 
app that reproduces it.  This isn’t expected behavior, and the teams at Apple 
are still working and would be very interested in seeing this.  Once filed, if 
you do find a workaround, you can append that to the bug.
--
Gary L. Wade
http://www.garywade.com/ 

> On Apr 19, 2020, at 10:58 AM, Allan Odgaard via Cocoa-dev 
>  wrote:
> 
> On 20 Apr 2020, at 0:37, Rob Petrovec wrote:
> 
>> >> I think you are right about this being a permission / “sandbox” issue, 
>> >> because the 3 folders in question are all folders that macOS 10.15 now 
>> >> require special permission to read (even though in my case, I just 
>> >> request their display name).
>>  Yes, this is because of iCloud.  Log out of iCloud and it should go 
>> away as I suggested in my first reply.  You could also grant your app full 
>> disk access and that might ‘fix’ it for you too.  But your users would 
>> probably not want to do that.
> 
> As written previously, there is no delay when running from terminal, and 
> ~/Downloads is also causing a delay, which is not stored on iCloud.
> 
> So this very much seems to be about Apple’s file system access policies where 
> permission must be obtained to access certain folders.
> 
> But as mentioned, I have given my app full disk access, reset permissions, 
> and I have even signed and notarized the app: Still no fix for the delay.
> 
> To indulge you, I have now also tried to log out of iCloud: Still a delay.
> 
> Now I would very much appreciate if someone would try the code I included in 
> my original email to see if this is a general problem, or something limited 
> to my system.
> 
> As I think I mentioned, I am running a fairly clean install of macOS 10.15.

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Performance issue on macOS 10.15 obtaining display name for ~/Desktop, ~/Documents, and ~/Downloads

[Allan Odgaard via Cocoa-dev]

On 20 Apr 2020, at 0:37, Rob Petrovec wrote:

>> I think you are right about this being a permission / “sandbox” 
issue, because the 3 folders in question are all folders that macOS 
10.15 now require special permission to read (even though in my case, 
I just request their display name).
	Yes, this is because of iCloud.  Log out of iCloud and it should go 
away as I suggested in my first reply.  You could also grant your app 
full disk access and that might ‘fix’ it for you too.  But your 
users would probably not want to do that.


As written previously, there is no delay when running from terminal, and 
~/Downloads is also causing a delay, which is not stored on iCloud.


So this very much seems to be about Apple’s file system access 
policies where permission must be obtained to access certain folders.


But as mentioned, I have given my app full disk access, reset 
permissions, and I have even signed and notarized the app: Still no fix 
for the delay.


To indulge you, I have now also tried to log out of iCloud: Still a 
delay.


Now I would very much appreciate if someone would try the code I 
included in my original email to see if this is a general problem, or 
something limited to my system.


As I think I mentioned, I am running a fairly clean install of macOS 
10.15.

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Performance issue on macOS 10.15 obtaining display name for ~/Desktop, ~/Documents, and ~/Downloads

[Rob Petrovec via Cocoa-dev]

>> I think you are right about this being a permission / “sandbox” issue, 
>> because the 3 folders in question are all folders that macOS 10.15 now 
>> require special permission to read (even though in my case, I just request 
>> their display name).
Yes, this is because of iCloud.  Log out of iCloud and it should go 
away as I suggested in my first reply.  You could also grant your app full disk 
access and that might ‘fix’ it for you too.  But your users would probably not 
want to do that.


>> That’s 181 milliseconds spent __WAITING_ON_APPROVAL_FROM_SANDBOXD__ in a 
>> non-sandboxed app obtaining display name for 3 folders in the user’s home 
>> directory.
Its actually worse then that.  At the top of the spindump file it says 
was the numbers represent.  Something like:

Duration: 10.00s
Steps:1001 (10ms sampling interval)

So 181 actually represents 1810ms, or 1.81 seconds.  So this is a sandbox 
performance issue.  Please file a bug and include a sysdiagnose as I suggested 
in my first reply.

—Rob



> On Apr 19, 2020, at 11:11 AM, Allan Odgaard via Cocoa-dev 
>  wrote:
> 
> On 19 Apr 2020, at 22:54, David M. Cotter wrote:
> 
>> i have discovered it may have to do with permissions / entitlements that 
>> have been granted the app by the user, and that resetting all perms to 
>> default will "fix" the problem
> 
> I think you are right about this being a permission / “sandbox” issue, 
> because the 3 folders in question are all folders that macOS 10.15 now 
> require special permission to read (even though in my case, I just request 
> their display name).
> 
> Furthermore, it could explain why there is no delay when launched from 
> terminal, as the process will inherit the entitlements of the terminal, which 
> may have some special entitlements for the full disk access.
> 
> Unfortunately though I can’t figure out *what* the problem is; running 
> `tccutil reset All` (and rebooting) did not fix it.
> 
> I have tried the code in question in a signed and notarized app that has been 
> granted full disk access, yet it still has the delay.
> 
> A spindump does indicate it is a “sandbox” issue:
> 
>   *182   getattrlist + 136 (kernel + 3512472) [0xff8000559898]
> *182   ??? (kernel + 3512820) [0xff80005599f4]
>   *181   ??? (kernel + 3501529) [0xff8000556dd9]
> *181   ??? (kernel + 3490836) [0xff8000554414]
>   *181   mac_vnode_check_access + 154 (kernel + 9093082) 
> [0xff8000aabfda]
> *181   hook_vnode_check_access + 167 (Sandbox + 39552) 
> [0xff7f823a7a80]
>   *181   sb_evaluate + 5004 (Sandbox + 67658) [0xff7f823ae84a]
> *181   approval_response_wait + 142 (Sandbox + 154851) 
> [0xff7f823c3ce3]
>   *181   __WAITING_ON_APPROVAL_FROM_SANDBOXD__ + 23 (Sandbox 
> + 155134) [0xff7f823c3dfe]
> *181   ??? (kernel + 6855402) [0xff8000889aea]
>   *181   thread_block_reason + 175 (kernel + 1317935) 
> [0xff8000341c2f]
> *181   ??? (kernel + 1324017) [0xff80003433f1]
>   *181   machine_switch_context + 200 (kernel + 
> 2388456) [0xff80004471e8]
> 
> That’s 181 milliseconds spent __WAITING_ON_APPROVAL_FROM_SANDBOXD__ in a 
> non-sandboxed app obtaining display name for 3 folders in the user’s home 
> directory.
> ___
> 
> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
> 
> Please do not post admin requests or moderator comments to the list.
> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
> 
> Help/Unsubscribe/Update your Subscription:
> https://lists.apple.com/mailman/options/cocoa-dev/petrock%40mac.com
> 
> This email sent to petr...@mac.com

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Performance issue on macOS 10.15 obtaining display name for ~/Desktop, ~/Documents, and ~/Downloads

[Allan Odgaard via Cocoa-dev]

On 19 Apr 2020, at 22:54, David M. Cotter wrote:

i have discovered it may have to do with permissions / entitlements 
that have been granted the app by the user, and that resetting all 
perms to default will "fix" the problem


I think you are right about this being a permission / “sandbox” 
issue, because the 3 folders in question are all folders that macOS 
10.15 now require special permission to read (even though in my case, I 
just request their display name).


Furthermore, it could explain why there is no delay when launched from 
terminal, as the process will inherit the entitlements of the terminal, 
which may have some special entitlements for the full disk access.


Unfortunately though I can’t figure out *what* the problem is; running 
`tccutil reset All` (and rebooting) did not fix it.


I have tried the code in question in a signed and notarized app that has 
been granted full disk access, yet it still has the delay.


A spindump does indicate it is a “sandbox” issue:

   *182   getattrlist + 136 (kernel + 3512472) [0xff8000559898]
 *182   ??? (kernel + 3512820) [0xff80005599f4]
   *181   ??? (kernel + 3501529) [0xff8000556dd9]
 *181   ??? (kernel + 3490836) [0xff8000554414]
   *181   mac_vnode_check_access + 154 (kernel + 9093082) 
[0xff8000aabfda]
 *181   hook_vnode_check_access + 167 (Sandbox + 39552) 
[0xff7f823a7a80]
   *181   sb_evaluate + 5004 (Sandbox + 67658) 
[0xff7f823ae84a]
 *181   approval_response_wait + 142 (Sandbox + 154851) 
[0xff7f823c3ce3]
   *181   __WAITING_ON_APPROVAL_FROM_SANDBOXD__ + 23 
(Sandbox + 155134) [0xff7f823c3dfe]

 *181   ??? (kernel + 6855402) [0xff8000889aea]
   *181   thread_block_reason + 175 (kernel + 
1317935) [0xff8000341c2f]
 *181   ??? (kernel + 1324017) 
[0xff80003433f1]
   *181   machine_switch_context + 200 (kernel 
+ 2388456) [0xff80004471e8]


That’s 181 milliseconds spent __WAITING_ON_APPROVAL_FROM_SANDBOXD__ in 
a non-sandboxed app obtaining display name for 3 folders in the user’s 
home directory.

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Performance issue on macOS 10.15 obtaining display name for ~/Desktop, ~/Documents, and ~/Downloads

[Rob Petrovec via Cocoa-dev]

I assume you have iCloud enabled.  If so, these three folders are ’special’.  
Try logging out of iCloud & rebooting and see if the problem persists.

I would also recommend filing a bug with Apple and include a sysdiagnose taken 
while the problem was reproducing (sudo sysdiagnose).  Or at least a spindump 
(sudo spindump) while the problem is reproducing.

—Rob



> On Apr 19, 2020, at 9:54 AM, David M. Cotter via Cocoa-dev 
>  wrote:
> 
> this may be difficult for other to repro
> 
> i have discovered it may have to do with permissions / entitlements that have 
> been granted the app by the user, and that resetting all perms to default 
> will "fix" the problem
> 
> in the terminal, do this:
>> tccutil reset All
> i expect that after that, your delay will disappear.
> 
> however, you'll have to manually re-authorize all apps in the system 
> prefs->security & privacy->privacy tab
> 
> i realize this is a "sweep the problem under the rug" rather than "fix the 
> problem" approach
> but hopefully this should give someone else a clue as to WHY this is 
> happening?
> 
> -dave
> 
>> On Apr 19, 2020, at 8:08 AM, Allan Odgaard via Cocoa-dev 
>>  wrote:
>> 
>> Starting with macOS 10.15 I have noticed that obtaining 
>> NSURLLocalizedNameKey, NSURLTagNamesKey, and even calling getxattr(), can 
>> cause a significant delay.
>> 
>> The code below, which gets NSURLLocalizedNameKey for 3 folders, takes 1.9 
>> seconds to execute on my system.
>> 
>> It appears though that it is only these 3 specific folders that has the 
>> problem.
>> 
>> Furthermore, the problem only happens when I include the code below in a GUI 
>> application which is launched via launch services. If I run the executable 
>> directly from a terminal then the code is near instant.
>> 
>> I tried to sample the code, and it appears that it calls out to some OS 
>> service/daemon. Presumably it never gets a response, and a timeout is 
>> triggered.
>> 
>> I wonder if anyone else has come across this? And maybe have discovered more 
>> info?
>> 
>> This is btw macOS 10.15.4 and a fairly stock system (new computer without 
>> migrating old data), and I noticed the problem some time ago, so it 
>> definitely existed before 10.15.4, but I never saw anything like this before 
>> upgrading to Catelina.
>> 
>>   NSTimeInterval startTime = NSDate.timeIntervalSinceReferenceDate;
>> 
>>   NSArray* urls = @[]
>>   [NSFileManager.defaultManager URLForDirectory:NSDesktopDirectory 
>> inDomain:NSUserDomainMask appropriateForURL:nil create:NO error:nil],,
>>   [NSFileManager.defaultManager URLForDirectory:NSDocumentDirectory 
>> inDomain:NSUserDomainMask appropriateForURL:nil create:NO error:nil]
>>   [NSFileManager.defaultManager URLForDirectory:NSDownloadsDirectory 
>> inDomain:NSUserDomainMask appropriateForURL:nil create:NO error:nil,
>>   ];
>> 
>>   NSString* localizedName;
>>   for(NSURL* url in urls)
>>   [url getResourceValue: forKey:NSURLLocalizedNameKey 
>> error:nil];
>> 
>>   NSLog(@"Duration %.03f", NSDate.timeIntervalSinceReferenceDate - 
>> startTime);
> 
> ___
> 
> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
> 
> Please do not post admin requests or moderator comments to the list.
> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
> 
> Help/Unsubscribe/Update your Subscription:
> https://lists.apple.com/mailman/options/cocoa-dev/petrock%40mac.com
> 
> This email sent to petr...@mac.com

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Performance issue on macOS 10.15 obtaining display name for ~/Desktop, ~/Documents, and ~/Downloads

[David M. Cotter via Cocoa-dev]

this may be difficult for other to repro

i have discovered it may have to do with permissions / entitlements that have 
been granted the app by the user, and that resetting all perms to default will 
"fix" the problem

in the terminal, do this:
> tccutil reset All
i expect that after that, your delay will disappear.

however, you'll have to manually re-authorize all apps in the system 
prefs->security & privacy->privacy tab

i realize this is a "sweep the problem under the rug" rather than "fix the 
problem" approach
but hopefully this should give someone else a clue as to WHY this is happening?

-dave

> On Apr 19, 2020, at 8:08 AM, Allan Odgaard via Cocoa-dev 
>  wrote:
> 
> Starting with macOS 10.15 I have noticed that obtaining 
> NSURLLocalizedNameKey, NSURLTagNamesKey, and even calling getxattr(), can 
> cause a significant delay.
> 
> The code below, which gets NSURLLocalizedNameKey for 3 folders, takes 1.9 
> seconds to execute on my system.
> 
> It appears though that it is only these 3 specific folders that has the 
> problem.
> 
> Furthermore, the problem only happens when I include the code below in a GUI 
> application which is launched via launch services. If I run the executable 
> directly from a terminal then the code is near instant.
> 
> I tried to sample the code, and it appears that it calls out to some OS 
> service/daemon. Presumably it never gets a response, and a timeout is 
> triggered.
> 
> I wonder if anyone else has come across this? And maybe have discovered more 
> info?
> 
> This is btw macOS 10.15.4 and a fairly stock system (new computer without 
> migrating old data), and I noticed the problem some time ago, so it 
> definitely existed before 10.15.4, but I never saw anything like this before 
> upgrading to Catelina.
> 
>NSTimeInterval startTime = NSDate.timeIntervalSinceReferenceDate;
> 
>NSArray* urls = @[]
>[NSFileManager.defaultManager URLForDirectory:NSDesktopDirectory 
> inDomain:NSUserDomainMask appropriateForURL:nil create:NO error:nil],,
>[NSFileManager.defaultManager URLForDirectory:NSDocumentDirectory 
> inDomain:NSUserDomainMask appropriateForURL:nil create:NO error:nil]
>[NSFileManager.defaultManager URLForDirectory:NSDownloadsDirectory 
> inDomain:NSUserDomainMask appropriateForURL:nil create:NO error:nil,
>];
> 
>NSString* localizedName;
>for(NSURL* url in urls)
>[url getResourceValue: forKey:NSURLLocalizedNameKey 
> error:nil];
> 
>NSLog(@"Duration %.03f", NSDate.timeIntervalSinceReferenceDate - 
> startTime);

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Performance issue on macOS 10.15 obtaining display name for ~/Desktop, ~/Documents, and ~/Downloads

[Allan Odgaard via Cocoa-dev]

Starting with macOS 10.15 I have noticed that obtaining 
NSURLLocalizedNameKey, NSURLTagNamesKey, and even calling getxattr(), 
can cause a significant delay.


The code below, which gets NSURLLocalizedNameKey for 3 folders, takes 
1.9 seconds to execute on my system.


It appears though that it is only these 3 specific folders that has the 
problem.


Furthermore, the problem only happens when I include the code below in a 
GUI application which is launched via launch services. If I run the 
executable directly from a terminal then the code is near instant.


I tried to sample the code, and it appears that it calls out to some OS 
service/daemon. Presumably it never gets a response, and a timeout is 
triggered.


I wonder if anyone else has come across this? And maybe have discovered 
more info?


This is btw macOS 10.15.4 and a fairly stock system (new computer 
without migrating old data), and I noticed the problem some time ago, so 
it definitely existed before 10.15.4, but I never saw anything like this 
before upgrading to Catelina.


NSTimeInterval startTime = NSDate.timeIntervalSinceReferenceDate;

NSArray* urls = @[]
[NSFileManager.defaultManager 
URLForDirectory:NSDesktopDirectory inDomain:NSUserDomainMask 
appropriateForURL:nil create:NO error:nil],,
[NSFileManager.defaultManager 
URLForDirectory:NSDocumentDirectory inDomain:NSUserDomainMask 
appropriateForURL:nil create:NO error:nil]
[NSFileManager.defaultManager 
URLForDirectory:NSDownloadsDirectory inDomain:NSUserDomainMask 
appropriateForURL:nil create:NO error:nil,

];

NSString* localizedName;
for(NSURL* url in urls)
[url getResourceValue: 
forKey:NSURLLocalizedNameKey error:nil];


NSLog(@"Duration %.03f", NSDate.timeIntervalSinceReferenceDate - 
startTime);

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com