Действия дерева (поиск) с использованием индексов (номера inode) для адресации файлов / каталогов

(удалено упоминание OS, так как мне нужно «общее решение Unix / Linux»)

Задача: выполнить операцию над файлами / каталогами в «find way», но при условии, что имена файлов / каталогов могут изменяться в процессе.

Типичная проблема с «нахождением» – это когда что-то переименовано, найти попытки ставить объект и сообщить, что он не может его найти. Если он будет работать с индексами, такая проблема не будет существовать (при стоимости обратного поиска, inode -> pathname и, возможно, дополнительного совпадения имен).

На данный момент я получаю список тематических файлов / каталогов, получаю их индексы и использую что-то вроде «find path -inum index», чтобы получить текущее имя для выполнения операции над файлом. Из-за этого сценарий выглядит довольно неуклюжим.

Есть ли более элегантный способ, возможно, есть клон «найти», способный работать с индексами, а не с кэшированными именами путей?

  • Невозможно создать файл * .o на разделе
  • Файловые системы против разделов и каталогов
  • Массовое удаление большого каталога на ZFS без его рекурсивного перемещения
  • Поиск файловой системы
  • Каково общее имя для каталогов. (точка) и .. (точка точка)?
  • Поиск разреженных файлов?
  • как устранить неполадки в том, действительно ли файловая система была размонтирована или нет.?
  • Является ли файловая система журналов хорошей идеей с зашифрованным диском dm-crypt?
  • One Solution collect form web for “Действия дерева (поиск) с использованием индексов (номера inode) для адресации файлов / каталогов”

    Из контекста я полагаю, что когда вы пишете «индексы», вы на самом деле означаете иноды . Если вы имели в виду индексы, обратите внимание, что каталог не состоит из списка файлов в четко определенном порядке, где вы можете сказать «Я хочу файл с индексом 3». Каталоги индексируются по именам: вы говорите: «Я хочу файл с именем foo ». Порядок файлов в каталоге может меняться в любое время.

    Предполагая, что вы имеете в виду inodes, нет способа получить доступ к файлу по его inode. Это по дизайну: пути к файлам – это то, как применяются права. Доступ к файлу с помощью inode приведет к обходу всех проверок разрешений в каталоге, который содержит его. Это также было бы возможно только в файловой системе, которая имеет концепцию inode по дизайну, вместо того, чтобы вытаскивать номера inode из тонкого воздуха только потому, что API требует этого. Поэтому, если вы знаете только индекс файла, ищите его, пока не найдете имя, это единственный способ работы с этим файлом.

    Даже если бы был способ найти файл inode, это не решило бы вашу проблему, это просто немного изменило бы его. Это сделает его прозрачным, когда файл будет переименован после find как find найдет его и прежде чем он что-то с ним сделает. Однако, если файл был удален, а другой файл был создан с тем же inode, find получит доступ к неправильному файлу.

    Нет никакого способа, с помощью API файлов, взять атомный снимок дерева каталогов. Есть несколько решений вашей проблемы; которые могут работать для вас, зависит от вашего сценария использования.

    • Убедитесь, что ваша задача справляется с изменениями дерева, на котором оно работает.
    • Убедитесь, что все приложения, которые изменяют дерево каталогов, приостановлены во время выполнения вашей задачи.
    • Используйте API нижнего уровня для создания моментального снимка и работы с моментальным снимком (только для чтения). Некоторые файловые системы, такие как zfs и btrfs, могут делать это, а также типы томов, такие как LVM.
    Linux и Unix - лучшая ОС в мире.