cocoa - 处理过时的 NSURL 书签的正确方法是什么？

Question

从安全范围的书签解析 NSURL 时，如果用户已重命名或移动该文件或文件夹，则该书签将过时。苹果的文档对于陈旧性有这样的描述:

isStale

On return, if YES, the bookmark data is stale. Your app shouldcreate a new bookmark using the returned URL and use it in place ofany stored copies of the existing bookmark.

不幸的是，这对我来说很少有用。它可能在 5% 的时间内有效。尝试使用返回的 URL 创建新书签会导致错误(代码 256)，并且在控制台中查看会显示一条来自 sandboxd 的消息，表示拒绝更新的 URL 上的文件读取数据。

注意 如果重新生成书签确实有效，则似乎只有在第一次重新生成时才有效。如果再次移动/重命名文件夹/文件，它似乎永远不会起作用。

我最初如何创建和存储书签

-(IBAction)bookmarkFolder:(id)sender {
  _openPanel = [NSOpenPanel openPanel];
  _openPanel.canChooseFiles = NO;
  _openPanel.canChooseDirectories = YES;
  _openPanel.canCreateDirectories = YES;
  [_openPanel beginSheetModalForWindow:self.window completionHandler:^(NSInteger result) {
    if (_openPanel.URL != nil) {
      NSError *error;
      NSData *bookmark = [_openPanel.URL bookmarkDataWithOptions:NSURLBookmarkCreationWithSecurityScope
                                  includingResourceValuesForKeys:nil
                                                   relativeToURL:nil
                                                           error:&error];
      if (error != nil) {
        NSLog(@"Error bookmarking selected URL: %@", error);
        return;
      }
      NSUserDefaults *userDefaults = [NSUserDefaults standardUserDefaults];
      [userDefaults setObject:bookmark forKey:@"bookmark"];
    }
  }];
}

解析书签的代码

-(void)resolveStoredBookmark {
  NSUserDefaults *userDefaults = [NSUserDefaults standardUserDefaults];
  NSData *bookmark = [userDefaults objectForKey:@"bookmark"];
  if (bookmark == nil) {
    NSLog(@"No bookmark stored");
    return;
  }
  BOOL isStale;
  NSError *error;
  NSURL *url = [NSURL URLByResolvingBookmarkData:bookmark
                                         options:NSURLBookmarkResolutionWithSecurityScope
                                   relativeToURL:nil
                             bookmarkDataIsStale:&isStale
                                           error:&error];
  if (error != nil) {
    NSLog(@"Error resolving URL from bookmark: %@", error);
    return;
  } else if (isStale) {
    if ([url startAccessingSecurityScopedResource]) {
      NSLog(@"Attempting to renew bookmark for %@", url);
      // NOTE: This is the bit that fails, a 256 error is 
      //       returned due to a deny file-read-data from sandboxd
      bookmark = [url bookmarkDataWithOptions:NSURLBookmarkCreationWithSecurityScope
               includingResourceValuesForKeys:nil
                                relativeToURL:nil
                                        error:&error];
      [url stopAccessingSecurityScopedResource];
      if (error != nil) {
        NSLog(@"Failed to renew bookmark: %@", error);
        return;
      }
      [userDefaults setObject:bookmark forKey:@"bookmark"];
      NSLog(@"Bookmark renewed, yay.");
    } else {
      NSLog(@"Could not start using the bookmarked url");
    }
  } else {
    NSLog(@"Bookmarked url resolved successfully!");
    [url startAccessingSecurityScopedResource];
    NSArray *contents = [NSFileManager.new contentsOfDirectoryAtPath:url.path error:&error];
    [url stopAccessingSecurityScopedResource];
    if (error != nil) {
      NSLog(@"Error reading contents of bookmarked folder: %@", error);
      return;
    }
    NSLog(@"Contents of bookmarked folder: %@", contents);
  }
}

当书签过时时，生成的解析 URL 确实指向正确的位置，尽管 [url startAccessingSecurityScopedResource] 返回 YES，但我实际上无法访问该文件。

也许我误解了有关过时书签的文档，但我希望我只是做了一些愚蠢的事情。每次重命名或移动带书签的文件/文件夹时弹出 NSOpenPanel，这是我目前唯一的其他选择，似乎很荒谬。

我应该补充一点，我有com.apple.security.files.bookmarks.app-scope，com.apple.security.files.user-selected.read-write em> 和 com.apple.security.app-sandbox 在我的权利文件中全部设置为 true。

Answer 1

经过大量令人失望的测试后，我得出以下结论。虽然合乎逻辑，但它们令人失望，因为用户的最终体验远非理想，并且对开发人员来说是一个巨大的痛苦，这取决于他们愿意在多大程度上帮助用户重新建立对书签资源的引用。

当我在下面说“更新”时，我的意思是“使用从过时书签解析的 URL 生成一个新书签来替换过时书签。”

1. 只要在您的应用已有权访问的目录中移动或重命名添加书签的资源，续订始终有效。因此，默认情况下，它始终在应用程序的容器文件夹中运行。

2. 如果将添加书签的资源移动到您的应用程序无权访问的文件夹中，则续订会失败。例如用户将文件夹从容器文件夹拖到容器文件夹外部的某个文件夹。您将能够解析该 URL，但无法访问或续订书签。

3. 如果加书签的资源位于您的应用程序无权访问的文件夹中，然后被重命名，则续订会失败。这意味着用户可以显式授予您的应用程序对资源的访问权限，然后仅通过重命名即可无意中撤销该访问权限。

4. 如果将资源移动到另一个卷，解决方案将失败。不确定这是否是书签的一般限制或仅在沙盒应用程序中使用时的限制。

对于问题 2 和 3，您作为开发人员处于一个不错的位置，因为添加书签的 URL 的解析确实有效。您至少可以通过准确地告诉用户需要哪些资源来授予您的应用程序访问权限以及这些资源的位置来引导用户。通过让他们选择一个包含(直接或间接)您需要为其续订书签的所有资源的文件夹，可以改善体验。这甚至可能是卷，如果他们愿意为您的应用程序提供这么多访问权限，则可以完全解决问题。

对于问题 4，解决方案根本不起作用。用户将不得不在没有任何提示的情况下重新定位文件，因为您无法解析新位置。我在当前的应用程序中所做的一件事减轻了这个问题的痛苦，那就是向我存储书签的任何资源添加扩展属性。这样做至少可以让用户选择一个文件夹来搜索以前关联的资源。

令人沮丧的限制，但书签仍然胜过存储静态路径。