为什么具有相同 iNode 的文件/硬链接比引用计数显示的要多?

发布于 2024-08-03 02:06:21 字数 1265 浏览 3 评论 0原文

我已经在单个卷上递归了一个文件夹,并使用

NSFileManager attributeOfItemAtPath

和 NSDictionary fileSystemFileNumber 和 objectForKey:NSFileReferenceCount

检索了文件名、引用计数和 inode 编号的列表由于某种原因,我得到的结果例如引用计数为 10,但是具有相同 iNode 编号的超过 10 个文件的列表。

值得注意的是,我没有在我的列表中包含符号链接,我只在 [dict fileType] == NSFileTypeRegular 时记录文件

任何想法为什么会出现这种情况?

编辑:@Peter Hosey,我正在编写 iNode 和引用计数,如下所示:

CLMFileManagedObj *clmf;
clmf = (CLMFileManagedObj *)[NSEntityDescription insertNewObjectForEntityForName:@"CLMFile" inManagedObjectContext:moc];

NSUInteger fsfn = [dict fileSystemFileNumber];
[clmf setValue:[NSNumber numberWithUnsignedInteger:fsfn] forKey:@"iNodeNumber"];
[clmf setValue:(NSNumber*)[dict objectForKey:NSFileReferenceCount] forKey:@"referenceCount"];

请注意,iNodeNumber 和 referenceCount 的编写略有不同的原因是 [dict] 提供了直接 (NSUInteger)fileSystemFileNumber 获取方法,而 fileReferenceCount 需要使用键检索(根据我在 NSDictionary 上找到的任何帮助)

CLMFile 实体的两个属性都是 Int 64。据我所知,NSUInteger 的类型取决于是否运行 32 位或 64 位模式,但是 [NSNumber numberWithUnsignedInteger]接受 NSUInteger 作为参数,所以我假设它在任一模式下都能正确处理数字。

我在活动监视器中看不到它是否是 32/64 位的位置。我假设 XCode 3.1.3 项目的默认值是什么。

我可能在这里遗漏了一些东西,因为我对 Mac/Obj-C/XCode/Cocoa 相对较新,所以任何帮助/指针将不胜感激。经验丰富的程序员,但不是在这个环境中(尽管我尽可能快地学习......)

I have recursed a folder on a single volume, and retrieved a list of filenames, reference-counts and inode numbers, using

NSFileManager attributesOfItemAtPath

and NSDictionary fileSystemFileNumber and objectForKey:NSFileReferenceCount

For some reason I am getting results such as a reference count of 10, but a list of many more than 10 files with the same iNode number.

Of note is that I am not including SymLinks in my list, I'm only recording a file when [dict fileType] == NSFileTypeRegular

Any ideas why this might be the case?

Edit: @Peter Hosey, I'm writing the iNode and reference count as follows:

CLMFileManagedObj *clmf;
clmf = (CLMFileManagedObj *)[NSEntityDescription insertNewObjectForEntityForName:@"CLMFile" inManagedObjectContext:moc];

NSUInteger fsfn = [dict fileSystemFileNumber];
[clmf setValue:[NSNumber numberWithUnsignedInteger:fsfn] forKey:@"iNodeNumber"];
[clmf setValue:(NSNumber*)[dict objectForKey:NSFileReferenceCount] forKey:@"referenceCount"];

Note that the reason iNodeNumber and referenceCount are being written slightly differently is that [dict] offers a direct (NSUInteger)fileSystemFileNumber get-method, whereas the fileReferenceCount needs to be retrieved using keys (according to any help I could find on NSDictionary)

Both properties of the CLMFile entity are Int 64. From what I can tell, NSUInteger's type is dependent on whether running 32 or 64 bit mode, but [NSNumber numberWithUnsignedInteger] accepts NSUInteger as the argument, so I'd assume it deals with the number correctly in either mode.

I can't see where in Activity Monitor it says whether it's 32/64 bit. I'd assume whatever the default for XCode 3.1.3 projects are.

It's possible I'm missing something here, as I'm relatively new to Mac/Obj-C/XCode/Cocoa, so any help/pointers would be appreciated. Experienced programmer, but not in this environment (though learning as fast as I can....)

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

梦里兽 2024-08-10 02:06:21

您在查看时间机器备份吗?是否涉及目录硬链接?

如果目录 A 包含硬链接的目录 B1 和 B2,则具有相同 inode 的文件将同时位于 B1 和 B2 内,但引用计数可能为 1。

Are you looking at Time Machine backups? Are there directory hardlinks involved?

If directory A contains directories B1 and B2 which are hardlinked, a file with the same inode would be inside both B1 and B2, yet the ref count could be one.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文