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/