имя файла и путь файла

Каталог содержит список имен файлов ⇒ inode mappings. Ваша директория /home/tim включает запись с именем файла tim.pdf, указывающую на (скажем) inode 1234.

Как нам попасть в эту директорию? Ну, каталог - это действительно специальный вид файла, который содержит эти записи. Мы можем найти его так же, как и другие файлы, посмотрев в его родительском каталоге: /home будет запись с именем файла tim, которая указывает на вход в каталог. В свою очередь, мы можем найти /home, посмотрев в его родительском файле, /.

/ - это корень, и он немного более особенный. Система знает, как добраться до него напрямую, потому что у него нет родителя.

Имя / файла - это локальное имя, которое он имеет в своем каталоге: tim.pdf. Путь файла описывает, как к нему попасть от корня: /home/tim/tim.pdf. Если хотите, можете считать, что это набор инструкций: сначала найдите /, затем внутри него найдите home, затем tim, и наконец tim.pdf, который вы искали.

Решение любого пути - это, по сути, рекурсивный алгоритм с этим псевдокодом:

inode find_file(inode where_i_am, string[] remaining_path):
    if remaining_path is empty:
         # Nothing more to look at - we've found the file!
         return where_i_am
    current_item = remaining_path[0]
    rest_of_path = remaining_path[1..]
    for entry in directory_entries(where_i_am):
        if entry.filename == current_item:
            return find_file(entry.inode, rest_of_path)
    return file not found

Мы бы нашли Ваш файл с:

find_file(inode_of_root, ["home", "tim", "tim.pdf"])

Есть несколько случаев, когда все немного усложняется, на которые псевдокод не распространяется. Один из них - mounts: когда вы монтируете другой раздел, скажем, /home, система помнит, что когда она переходит в /home, она должна переключиться на этот другой раздел и начать искать tim в корне этой файловой системы, а не в ней. Новая файловая система будет иметь свой собственный набор кодов, поэтому для доступа к данным файла необходимо знать как коды, так и устройство. Реальная структура на самом деле включает в себя и то, и другое.

Символические ссылки говорят системе идти и искать какой-нибудь другой путь в этот момент, а затем продолжать поиск с этого нового места.

Другой случай - жесткие ссылки (ваш старый друг). Обычный файл inode может иметь произвольное количество жестких ссылок на него. Вы можете сделать ссылку с ln tim.pdf pdf.tim, которая будет иметь то же самое содержимое и жить в той же точке на диске. Там была бы отдельная запись каталога pdf.tim, которая указывала бы на тот же самый inode 1234, что и запись для tim.pdf. Наш алгоритм отлично работает в данном случае: жесткая ссылка на файл точно такая же, как и в оригинальном файле, и нам не нужно его никак различать. Дело в том, что жесткая ссылка - это просто другое имя для инода, поэтому нельзя делать жесткие ссылки через файловые системы.

Еще одна особенность - это специальные записи ... и .... Это (часто, но в зависимости от файловой системы) реальные записи каталогов. По сути, это жесткие ссылки на саму директорию и ее родителя. Наш алгоритм с этим тоже разбирается. Есть интересный случай, придуманный mounts: так как базовая файловая система не знает, куда она будет смонтирована, она не может иметь нужную запись .... Чтобы справиться с этим, система, по сути, обманывает и показывает запись ... из каталога на родительском устройстве, а не из корня смонтированной файловой системы.

Итак, когда вы смотрите на вещи с точки зрения inodes, то:

• A имя файла - это имя, которое называется внутри определённого каталога.
• Путь - это некоторые инструкции, как добраться до инода из известной точки.

В общем, пафос и одинаковые имена . Во-первых, ознакомьтесь с некоторыми правилами для имён файлов из документации POSIX:

4.6 Имена файлов

Для того, чтобы имя файла можно было переносить в различных реализациях, отвечающих следующим требованиям IEEE Std 1003.1-2001, он должен состоять только из портативного имени файла Набор символов, как определено в Переносном наборе символов имени файла.

Символ дефиса не должен использоваться в качестве первого символа портативное имя. Прописные и строчные буквы должны сохранять свои уникальная идентичность между соответствующими реализациями. В случае портативное имя, также может быть использован символ косой черты.

Вы можете видеть, что в данном разделе используется имя файла и путь , которые являются взаимозаменяемыми.

Также существует различие между ними в процессе, называемом Разрешение патнама:

4.11 Разрешение патнама

Разрешение патнама выполняется для процесса разрешения патнама. к определенному файлу в файловой иерархии. Их может быть несколько имена, которые разрешаются в один и тот же файл.

Каждое имя файла в патнаме находится в директории, определяемой его предшественник (например, в фрагменте пути a/b, файл b - это расположенный в каталоге a). Разрешение патнама должно быть неудачным, если это не может будет выполнено. Если отчество начинается с косой черты, то предшественник от первого имени в отчестве принимается за корень. каталог процесса (такие патнамы называются "абсолютный отчество"). Если отчество не начинается с косой черты, то предшественником первого фильтра патентона считается текущую рабочую директорию процесса (такими именами являются именуемых "относительными прозвищами").

pathname разрешается в файл, а имя файла находится в каталоге, указанном его предшественником.

Примечание

• POSIX Разрешение пути_решения
• path_resolution