objective-c – 沙盒Mac应用程序耗尽安全范围的URL资源

概述我正在开发一个Mac应用程序,提示用户使用NSOpenPanel的文件.该应用程序是沙盒(在OSX 10.9.4上进行测试).我注意到,如果我打开大量文件(〜3000),打开的面板开始向日志发出错误.如果我尝试在卡盘中打开较少数量的文件多次,也会发生这种情况. 错误首次出现后,每次NSOpenPanel再次使用文件打开时,无论文件多少,这些错误将再次生成(直到应用程序关闭). 错误消息如下所示： 我正在开发一个Mac应用程序,提示用户使用NSOpenPanel的文件.该应用程序是沙盒(在OSX 10.9.4上进行测试).我注意到,如果我打开大量文件(〜3000),打开的面板开始向日志发出错误.如果我尝试在卡盘中打开较少数量的文件多次,也会发生这种情况.

错误首次出现后,每次NSOpenPanel再次使用文件打开时,无论文件多少,这些错误将再次生成(直到应用程序关闭).

错误消息如下所示：

TestPanel[98508:303] __41+[NSSavePanel _consumeSandBoxExtensions:]_block_invoke: sandBox_consume_fs_extension Failed

我尝试打开每个文件的一行.

我设法通过一个简单的应用程序来重现这个行为：一个沙盒应用程序,一个单一的按钮调用下面的代码：

NSOpenPanel* panel = [NSOpenPanel openPanel];[panel setAllowsMultipleSelection:YES];[panel setCanChooseDirectorIEs:NO];[panel setCanChoosefiles:YES];[panel beginSheetModalForWindow:[self window] completionHandler:^(NSInteger result) {    NSLog(@"%lu",[panel.URLs count]);}];

错误出现在代码到达完成处理程序之前.

似乎我仍然可以从完成处理程序中的面板获取URL,但它真的会污染系统日志.

编辑：

似乎这个问题与NSOpenPanel / NSSavePanel面板没有直接关系.当使用drap / drop文件时,会发生类似的事情.这样的事情

- (NSDragOperation)draggingEntered:(ID <NSDraggingInfo>)sender {    ...    NSPasteboard *pboard = [sender draggingPasteboard];    if ([[pboard types] containsObject:NSURLPboardType]) {        NSArray *urls = [pboard readobjectsForClasses:@[[NSURL class]] options:nil];    }    ...}

当拖动大量文件时,这将生成以下日志消息(“魔术”数字似乎在2900左右)：

Consume sandBox extension for itemIDentifIEr (2937) from pasteboard Failed!

与NSOpenPanel一样,在第一次出现之后,每个单个文件丢失将在日志中生成相同的错误.

编辑2：

@mahal tertin的回答指向我正确的方向.问题确实在于文件的数量以及安全范围的URL资源有限的事实.

然而,似乎没有找到合理的解决方案.问题是当用户点击NSOpenPanel上的“OK”(或者拖放和拖放感知控件上的文件)时, *** 作系统已经尝试创建这些安全范围的URL,并为您隐式调用startAccessingSecurityScopedResource.因此,如果用户尝试打开比限制更多的文件,则资源耗尽,唯一的选项是关闭并重新启动应用程序.

在返回的URL上调用stopAccessingSecurityScopedResource似乎释放了这些资源,但是这个解决方案在苹果公司的official developers forums代表中是不鼓励的(链接在登录后面).

似乎该应用程序受到用户不允许打开太多文件的怜悯.那甚至不是一次,因为没有批准的方式来释放这些资源.您可以通过文档或甚至使用应用内警告来警告用户,但是没有办法阻止他们弄乱应用程序并强制重新启动.

因此,如果应用程序运行时间足够长,用户继续打开文件,该应用程序将最终变得无法使用.

仍在寻找一个合理的解决方案.

解决方法 经过高低搜索,在各地询问,我将要解决这个问题,并得出结论,没有答案或解决方案.我发布已知的信息,供将来参考.

建议的所有解决方案只是解决方法,可以最小化问题,并尝试引导用户不要尝试打开太多的文件.但实际上没有什么可以做到这一点.

以下是有关此问题的已知事实：

>无论做什么,用户都可以尝试在NSOpenPanel对话框中打开太多的文件,并耗尽安全范围的URL资源
>一旦这些资源耗尽,就不可能再打开任何更多的文件进行阅读/写入.该应用程序需要关闭并重新打开
>即使用户不尝试同时打开太多文件,如果应用程序运行足够长时间,并且用户随着时间推出足够的文件,仍可能耗尽这些资源,因为startAccessingSecurityScopedResource会自动为使用NSOpenPanel打开的文件(或拖放机制),没有关闭这些资源
>在开放式面板检索的所有URL上调用stopAccessingSecurityScopedResource将释放这些资源,但Apple不鼓励这种做法,表示它可能与未来的解决方案不兼容
>当您从NSOpenPanel(或拖放)收到URL列表时,无法确定所有URL是否已成功访问,或者是否存在超出限制因此无效的URL.
>苹果知道这一点,可能会在将来解决它.它仍然在10.10中仍然不固定,当然这不会帮助目前应用程序在当前/以前的OSX版本上运行.

看来,苹果公司真的把球放在了这一个上,沙盒实施看起来非常马虎,视线短视.

总结

以上是内存溢出为你收集整理的objective-c – 沙盒Mac应用程序耗尽安全范围的URL资源全部内容，希望文章能够帮你解决objective-c – 沙盒Mac应用程序耗尽安全范围的URL资源所遇到的程序开发问题。

如果觉得内存溢出网站内容还不错，欢迎将内存溢出网站推荐给程序员好友。