可以使用inode和crtime作为唯一的文件标识符吗?

我在Linux上有一个文件索引数据库。 目前我使用文件path作为标识符。 但是,如果一个文件被移动/重命名,其path被改变,我无法将我的数据库logging匹配到新文件,并且必须删除/重新创buildlogging。 更糟的是,如果一个目录被移动/重命名,那么我必须删除/重新创build所有文件和嵌套目录的logging。

我想使用inode号码作为唯一的文件标识符,但是如果删除文件并创build另一个文件,则可以重新使用inode号码。

所以,我想知道是否可以使用一对{inode,crtime}作为唯一的文件标识符。 我希望在NTFS上使用ext4和creation_time上的i_crtime。 在我有限的testing中(使用ext4)inode和crtime确实在同一个文件系统中重命名或移动文件或目录时保持不变。

那么问题是,是否有文件的inode或crtime可能会改变的情况。 例如,可以fsck或碎片整理或分区大小更改inode或crtime或文件?

有趣的是http://msdn.microsoft.com/en-us/library/aa363788%28VS.85%29.aspx说:

  • 在NTFS文件系统中,文件保持相同的文件ID,直到它被删除。
    但也:
  • 在某些情况下,文件的文件ID可能随时间而改变。

那么,他们提到的是什么呢?

请注意,我研究了类似的问题:

  • 如何确定在Linux中的文件的唯一性?
  • 执行'mv A B':'inode'会被改变吗?
  • 在Linux中检测移动或重命名为文件的最佳方法?

但他们不回答我的问题。

Solutions Collecting From Web of "可以使用inode和crtime作为唯一的文件标识符吗?"

  • {device_nr,inode_nr}是系统中 inode的唯一标识符
  • 将文件移动到其他目录不会更改其inode_nr
  • Linux inotify接口使您能够监视对inode(文件或目录)的更改

额外的笔记:

  • 在文件系统中移动文件的处理方式不同。 (这实际上是复制+删除)
  • 联网的文件系统(或者安装的NTFS)并不总能保证inodenumbers的稳定性
  • 微软并不是 unix的供应商,其文档不包括Unix或其文件系统,应该被忽略(NTFS的内部除外)

额外的文本:旧的Unix adagium“一切都是文件”其实应该是:“一切都是inode”。 inode携带所有关于文件(或目录或特殊文件)的名称以外的元信息。 文件名实际上只是一个恰好链接到特定inode的目录条目。 移动文件意味着:创建一个新的链接到同一个索引节点,结束删除链接到它的旧的目录条目。 inode元数据可以通过stat()fstat()lstat()系统调用获得。

Unix中i节点的分配和管理取决于文件系统。 所以,对于每个文件系统,答案可能会有所不同。

对于Ext3文件系统(最流行的),i节点被重用,因此不能被用作唯一的文件标识符,也不会根据任何可预测的模式重复使用。

在Ext3中,i节点在一个位向量中被跟踪,每一位表示一个i节点号。 当i节点被释放时,它的位被设置为零。 当需要新的i节点时,搜索位矢量的第一个零位,并且i节点号码(可能已经被分配给另一个文件)被重新使用。

这可能导致天真的结论,即编号最小的可用i节点将是重用的节点。 但是,Ext3文件系统是复杂且高度优化的,因此不应该假定i-节点号码何时以及如何重用,尽管它们显然会。

从ialloc.c的源代码中分配i节点:

有两个分配inode的策略。 如果新的索引节点是一个目录,则向前搜索具有空闲空间和较低的目录 – 索引节点比率的块组; 如果这个失败了,那么那些空闲空间高于平均水平的组,那么已经选择了那些目录数量最少的组。 对于其他inode,从父目录的块组向前搜索以查找空闲inode。

管理Ext3的源代码被称为ialloc,最终版本在这里: https : //github.com/torvalds/linux/blob/master/fs/ext3/ialloc.c