Файл может быть получен его inode?

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

Был предложенный патч к ядру Linux, чтобы позволить создавать ссылку на файл от дескриптора файла. Это было отклонено, потому что реализация этого надежно будет чрезвычайно трудна.

В соответствии с Linux (и вероятно на других вариантах Unix по той же причине), Вы не можете создать ссылку на удаленный файл, поэтому если файл больше не имеет имя, Вы не можете повторно добавить тот. ¹ Вы может открыть удаленный файл путем открытия волшебных ссылок под /proc/$pid/fd/.

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

¹ _{Вы могут делать это путем вертения байтов непосредственно в файловой системе зависимым от файловой системы способом, например, с debugfs для ext2/ext3/ext4. Это требует доступа к устройству, на котором файловая система смонтирована (т.е. обычно только базируйтесь, может делать попытку его). Однако, в то время как debugfs может получить доступ к файлу inode, это не помогает, если файл удален: файл будет действительно удален, если приложение закроется, это, и работающий debugfs в режиме чтения-записи в смонтированной файловой системе является залог провала.}

На Linux, debugfs, интерактивный ext2/ext3/ext4 отладчик файловой системы обеспечивает a ln команда, которая может взять inode число как filespec и создайте новую жесткую ссылку на соответствующий файл. На практике, хотя, это требует, чтобы несвязанный файл был сохранен открытым процессом, поддержав открытый дескриптор файла в /proc/[pid]/fd/[n]. Попытка этого находится на удаленном файле, скорее всего, приведет к повреждению файловой системы.

Это вызвано тем, что, чтобы удостовериться, что ext3 (и в расширении ext4) может безопасно возобновить удаление связь после катастрофического отказа, это на самом деле нули указатели блока в inode, тогда как ext2 просто отмечает эти блоки как неиспользованные в блоке, побитово отображает и отмечает inode, как "удалено" и оставляет указатели блока в покое. Несмотря на это, поскольку файловая система должна быть смонтированным чтением-записью для создания жесткой ссылки, блоки, зарезервированные для удаленного файла, возможно, уже были перераспределены.

До версии 2.6.39 ядра это раньше было что ln -L|--logical опция, представленная в GNU coreutils v8.0, могла использоваться для восстановления несвязанного файла через открытый дескриптор файла в /proc/[pid]/fd/[n] если и несвязанный файл и новый hardlink находились в tmpfs файловой системе. Эта возможность была с тех пор отключена, из-за, как Gilles указал, соображения безопасности, вовлеченные в разрешение создания жесткой ссылки непосредственно от дескриптора файла.

Команды 'ln' и 'rm' работали точно так же в каждой файловой системе UNIX с начала 1970-х годов. Mac OSX, BSD и Linux унаследовали этот оригинальный дизайн.

Сам по себе файл UNIX не имеет имени, только номер inode или inum. Но вы можете получить к нему доступ только через запись в специальном файле «каталога», который связывает имя с рассматриваемым inum; вы не можете напрямую указать inum.

Каталог является сам файлом, поэтому вы также должны получить доступ к его через (другой) каталог и так далее, через серию имен каталогов, разделенных косой чертой (/) известное как «имя пути». Путь начинается в «текущем рабочем каталоге» процесса, если имя не начинается с «/», и в этом случае он начинается с корневого каталога файловой системы. Например, если имя пути не содержит символов «/», то ожидается, что это будет запись в текущем каталоге.

Файл, не являющийся каталогом, может иметь любое количество путевых имен, известных как «жесткие ссылки», и он будет существовать до тех пор, пока все его путевые имена не будут удалены и ] последний процесс закрыл файл. Затем файл фактически удаляется, а его пространство помечается как доступное для повторного использования. То есть вы можете создать () или открыть () односвязный файл, а затем отключить его (), чтобы он больше не отображался в пространстве имен файловой системы, но файл продолжит существовать, пока вы его не закроете. Это полезно для временных рабочих файлов, которые не будут прочитаны другими программами.

Хотя каталоги имеют номера inode, в большинстве файловых систем жесткие ссылки на них запрещены; они могут появляться только в одном другом каталоге. (Одно необычное исключение - файловая система Mac OSX HFS +; это позволяет резервному копированию Time Machine работать.) Вы по-прежнему можете создавать «программные ссылки» на каталоги (или любой другой файл). Программная ссылка похожа на запись в каталоге, за исключением того, что она содержит другое имя пути, а не inum.

Каждый файл UNIX имеет владельца, группу и права доступа. Это необходимо, но недостаточно, чтобы они позволили вам открыть файл; вы также должны иметь как минимум разрешение на выполнение для каждого каталога в имени пути, которое вы используете для ссылки на него. Вот почему не существует стандартного способа открыть файл UNIX по его номеру inode; это позволит обойти важный, широко используемый механизм безопасности.

Но это не объясняет, почему не может быть стандартного способа для root (привилегированного) пользователя открыть файл по номеру inode, поскольку проверка разрешений в любом случае обходится.Это было бы очень полезно для определенных функций управления системой, таких как резервное копирование. Насколько мне известно, такие механизмы существуют, но все они зависят от файловой системы; не существует общего способа сделать это для любой файловой системы UNIX.

Вопрос может быть взят теоретически (что может быть достигнуто приdebugfs)или прагматически (чрезвычайной ситуации ). В последнем случае я предполагаю, что цель состоит в том, чтобы спасти положение и восстановить содержимое файла, возможно, в срочном порядке (, и именно так я пришел к этому вопросу, поэтому я думаю, что он все еще актуален и полезен ).

Поскольку API ядра отсутствует, debugfsне следует запускать в работающей файловой системе, поскольку она напрямую манипулирует структурой файловой системы. Поэтому, чтобы сделать это вживую, вам нужно получить другое имя файла. Предполагая, что файл все еще открыт каким-то процессом (любым процессом ), можно найти удобные файловые дескрипторы в/proc:

$ lsof -F pf "$PWD/a" | sed 's/^p//' # find pid and file descriptor number of any process having the file open
$ pid=1234
$ ls -l /proc/$pid/fd/* | grep "$PWD/a" # find file descriptor number
$ fd=42
$ cat /proc/$pid/fd/$fd > "$PWD/a.restored" # read contents to a new filename

Советы:

• если у вас есть сомнения по поводу правильного fd, вы можете запустить на нем такие команды, как file
• Если есть процесс, выполняющий запись в файл, обязательно остановите этот процесс как можно скорее, иначе вы не получите последние данные. (Непроверенный )трюк может состоять в том, чтобы открыть файл только для чтения через fd с помощью какого-либо другого процесса (попробовать tail -f < /proc/$pid/fd/$fd > /dev/null, выйти из процесса записи, чтобы он завершился корректно, и использовать fd нового процесса.