OSX Yosemite在NSURL上引入了一个非常方便的属性：NSURLDocumentIdentifierKey。
引用文档：
NSURLDocumentIdentifierKey
作为NSNumber返回的文档标识符（只读）。
文档标识符是内核分配给文件或目录的值。该值用于标识文档，而不管其在卷上的移动位置。该标识符在系统重新启动后仍然存在。复制文件时不会传输该文件，但是它可以进行“安全保存”操作，例如，即使调用了replaceItemAtURL：withItemAtURL：backupItemName：options：resultingItemURL：error：方法，该文件仍保留在分配路径上。文档标识符仅在单个卷中是唯一的，并非所有卷都支持此属性。
在OS X v10.10和iOS 8.0中可用。
不幸的是，该值似乎几乎为零（除了极少数例子似乎彼此完全断开）。
特别是，此代码将在最后一行抛出异常（在Yosemite 10.10.3上测试）：
NSFileManager *fileManager = [NSFileManager defaultManager];
NSArray *attributesFlags = @[NSURLNameKey, mNSURLDocumentIdentifierKey];
NSDirectoryEnumerator *en = [fileManager enumeratorAtURL:[NSURL URLWithString:NSHomeDirectory()]
includingPropertiesForKeys:attributesFlags
options:NSDirectoryEnumerationSkipsHiddenFiles
errorHandler:^BOOL(NSURL *url, NSError *error) {
NSAssert(NO, @"An error has occured");
return YES;
}];
for(NSURL *URL in en) {
NSNumber *documentID = nil;
NSError *error = nil;
BOOL result = [URL getResourceValue:&documentID forKey:NSURLDocumentIdentifierKey error:&error]; \
NSAssert(result == YES && error==nil, @"Unable to read property. Error: %@", error); \
NSLog(@"Processing file: %@", URL);
// This will break most of the times
NSAssert(documentID != nil, @"Document ID should not be nil!!");
}
也许我误解了文档，但在我看来
NSURLDocumentIdentifierKey应该在磁盘上的每个文件上都可用。 最佳答案
我在此问题上向Apple提交了一个错误，并收到了关于我的报告的反馈。到今天为止，有关跟踪DocumentIdentifier的信息尚未成为文档的一部分，但故障单仍处于打开状态。
缺少的信息是，文件系统默认情况下不跟踪DocumentIdentifier。您必须通过使用chflags和UF_TRACKED标志在每个要跟踪的文件上设置一个标志来启用跟踪。
以下脚本将打印文件的DocumentIdentifier：
https://gist.github.com/cmittendorf/fac92272a941a9cc64d5
并且此脚本将启用跟踪DocumentIdentifier：
https://gist.github.com/cmittendorf/b680d1a03aefa08583d7
关于objective-c - 为什么NSURL的NSURLDocumentIdentifierKey(几乎)总是为零？，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/29752914/