(为什么)是FSCTL_SET_OBJECT_ID危险?

NTFS文件可以有对象标识符。 这些ID可以使用FSCTL_SET_OBJECT_ID来设置。 但是, msdn文章说:

修改对象标识符可能会导致文件部分的数据丢失,直到并包括整个数据卷。

但是没有更详细的介绍。 这怎么会导致数据丢失? 它是否在文件系统中讨论潜在的对象标识冲突,而NTFS是否以某种方式依赖它们?

边节点:在find这个段落之前,我做了一些尝试,并设置了一些新创build文件的对象ID,希望我的文件系统仍然完好无损。

我真的不认为这会直接导致数据丢失。

唯一可以想象的是,如果一个备份程序假设(1)每个文件都有一个对象ID,(2)该程序始终跟踪所有的ID。 在这种情况下,它可能会假定不在其数据库中的ID必须引用不应该存在的文件,并且可能会删除该文件。

是的,我知道这听起来很荒谬,但这是我能想到的唯一方法。 我不认为你可以通过改变ID来丢失数据。

它们被分布式链接跟踪服务使用,它使客户端应用程序能够跟踪已经移动的链接源。 链接跟踪服务仅通过使用这些对象标识符(ID)来维护其与对象的链接。

所以回到你的问题,

是否在文件系统中讨论潜在的对象ID冲突?

我不这么认为。 Windows确实为我们提供了使用FSCTL_SET_OBJECT_ID设置对象ID的选项,但是这不会带来ID冲突的风险。 尝试在已经具有对象标识符的对象上设置对象标识符将失败。

..而NTFS是否以某种方式依赖于它们?

是。 对象标识符用于跟踪文件和目录 。 所有对象ID的索引都存储在卷上。 重命名,备份和还原操作保留对象ID。 但是,复制操作不保留对象ID,因为这会违反它们的唯一性。

这怎么会导致数据丢失?

如果您更改(或者更确切地说)设置用户创建的文件的对象ID(如您所做的那样),则不会遇到严重的问题。 但是,如果用户(有意/无意地)设置共享对象文件/库使用的对象ID,则更改将不会按原样反映。

由于Windows不希望每个人(但是开发人员)都使用关键库文件,所以它会发出一个通用的警告:

修改对象标识符可能会导致文件部分的数据丢失,直至包括整个数据卷。

底线:如果你知道你在做什么,就改变它。

另外还有一篇关于分布式链接跟踪和对象标识符的msn 文章 。

希望能帮助到你!

编辑

感谢@Mehrdad指出。我不是指DLL自己的对象标识符,而是它们在内部使用的对象标识符。

OLEACC(一个dll)提供了Active Accessibility运行时,并管理来自Active Accessibility客户端的请求[source] 。 它使用OBJID_QUERYCLASSNAMEIDX对象标识符[ source ]