Можно ли использовать inode и crtime как уникальный идентификатор файла?

У меня есть база данных индексирования файлов на Linux. В настоящее время я использую путь к файлу в качестве идентификатора. Но если файл перемещается/переименовывается, его путь изменяется, и я не могу сопоставить свою запись с базой данных с новым файлом и удалять/воссоздавать запись. Хуже того, если каталог перемещается/переименовывается, мне приходится удалять/воссоздавать записи для всех файлов и вложенных каталогов.

Я хотел бы использовать номер inode в качестве уникального идентификатора файла, но номер inode можно использовать повторно, если файл удален, а другой файл создан.

Итак, интересно, могу ли я использовать пару {inode,crtime} как уникальный идентификатор файла. Я надеюсь использовать i_crtime на ext4 и creat_time на NTFS. В моем ограниченном тестировании (с ext4) inode и crtime действительно остаются неизменными при переименовании или перемещении файлов или каталогов в пределах одной файловой системы.

Итак, вопрос в том, есть ли случаи, когда inode или crtime файла могут измениться. Например, может ли fsck или дефрагментация или изменение размера раздела изменить inode или crtime или файл?

Интересно, что http://msdn.microsoft.com/en-us/library/aa363788%28VS.85%29.aspx говорит:

  • "В файловой системе NTFS файл сохраняет тот же идентификатор файла, пока он не будет удален."
    но также:
  • "В некоторых случаях идентификатор файла для файла может меняться со временем".

Итак, что они упомянули в этих случаях?

Обратите внимание, что я изучил похожие вопросы:

но они не отвечают на мой вопрос.

Ответы

Ответ 1

  • {device_nr, inode_nr} - уникальный идентификатор для inode в системе
  • перемещение файла в другой каталог не изменяет его inode_nr
  • интерфейс linux inotify позволяет отслеживать изменения в inodes (файлы или каталоги).

Дополнительные примечания:

  • перемещение файлов в файловых системах осуществляется по-разному. (это infact copy + delete)
  • сетевые файловые системы (или смонтированные NTFS) не всегда гарантируют стабильность inodenumbers
  • Microsoft не является поставщиком Unix, ее документация не распространяется на Unix или ее файловые системы и должна игнорироваться (кроме внутренних NTFS).

Дополнительный текст: старый adagium Unix "все является файлом" на самом деле должен быть: "все является inode". Индекс несет всю метаинформацию о файле (или каталоге или специальном файле) кроме имени. Имя файла на самом деле является только записью в каталоге, которая связана со ссылкой на конкретный индекс. Перемещение файла подразумевает: создание новой ссылки на один и тот же индекс, завершение удаления старой записи каталога, связанной с ней. Метаданные inode можно получить с помощью системных вызовов stat() и fstat() и lstat().

Ответ 2

Распределение и управление i-узлами в Unix зависит от файловой системы. Таким образом, для каждой файловой системы ответ может отличаться.

Для файловой системы Ext3 (наиболее популярной) i-узлы повторно используются и, следовательно, не могут использоваться как уникальный идентификатор файла, и повторное использование не выполняется в соответствии с любым предсказуемым шаблоном.

В Ext3 i-узлы отслеживаются в битовом векторе, каждый бит представляет один номер i- node. Когда i- node освобождается, бит устанавливается в ноль. Когда требуется новый i-node, бит-бит ищет первый нулевой бит, а номер i- node (который ранее был выделен другому файлу) используется повторно.

Это может привести к наивному выводу о том, что наименьшее количество доступных i- node будет использоваться повторно. Тем не менее, файловая система Ext3 является сложной и оптимизированной, поэтому не следует делать никаких предположений о том, когда и как i- node числа могут быть повторно использованы, хотя они явно будут.

Из исходного кода для ialloc.c, где выделяются i-узлы:

Существует две политики для назначения индексного дескриптора. Если новый индексный дескриптор, то выполняется поиск в прямом порядке для группы блоков с обоими свободное пространство и низкое отношение каталога к inode; если это не удастся, то он группируется со средним свободным пространством, эта группа с наименьшим количеством каталоги уже выбраны. Для других инодов поиск вперед родительскую группу блоков каталогов, чтобы найти бесплатный индексный дескриптор.

Исходный код, который управляет этим для Ext3, называется ialloc, а окончательная версия здесь: https://github.com/torvalds/linux/blob/master/fs/ext3/ialloc.c