Чем различаются абсолютное и относительное имена файла

Обновлено: 07.07.2024

твой сайт существует в как бы в двух измерениях.
Реальном и виртуальном.

Для разработчика же сайт - это программа, выполняющаяся на совершенно конкретном реальном компьютере. С совершенно конкретным жестким диском, каталогами и файлами. И скрипт, работая со своими данными, подгружая другие скрипты, работает именно с реальными ФАЙЛАМИ, на физическом ДИСКЕ.

А всего-то надо четко понимать две вещи:
1. Различать корень веб-сервера, как его видит браузер, и корень файловой системы на диске.
2. Отличие относительных путей от абсолютных.

Начнем со второго.
Это очень просто. Если путь указывается от корня системы, то это путь абсолютный. Это как почтовый адрес в реальной жизни - откуда бы ты не шел, но по точному адресу ты всегда точно найдешь нужное место.
примеры абсолютных путей:
/var/www/site/forum/index.php
/img/frame.jpg
с:\windows\command.com
В юникс-системах и на веб сайтах корень обозначается косой чертой - "/".
Это важно. Это не просто палочка, а самостоятельный АДРЕС, путь.
В адресе http://www.site.ru/ последняя косая черта - не для красоты! Она обозначает вполне конкретный адрес - начало сайта.
На диске в юникс системах так же можно набрать "cd /" и ты попадешь в корневой каталог.
В виндоус системах файловая система разбивается по дискам, поэтому, в абсолютном адресе надо указывать имя диска. Абсолютного корня всей файловой системы в виндоус нет, у каждого диска - свой. Например, C:\ E:\
поэтому, даже если путь в виндоус начинается с косой черты, то это не абсолютный путь, а относительный. Относительно текущего диска. А абсолютный начинается с буквы.

Если в начале пути корень не указать, то этот путь будет относительным, и он достаивается от текущего положения. В реальной жизни это напоминает дорогу к винному магазину - "два квартала налево и там все время прямо". Дойти по такому пути можно только из конкретной точки. Из другой ты попадешь уже в совсем другое место.
Самый простой пример относительного пути - это просто имя файла.
Если файл находится в том же каталоге, с которым работает программа - она его найдет, добавив текущий путь к имени файла.
примеры относительных путей:
file.php (фал лежит в той же папке)
./file.php (фал лежит в той же папке. такая запись иногда требуется в некоторых юникс системах)
images/picture.jpg (файл лежит в капке images, которая находится в текущей)
../file.php (файл лежит в папке, которая расположена на один уровень выше от текущей)
../../file.php (файл лежит в папке, которая расположена на два уровня выше от текущей)

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


PHP предоставляет множество средств для работы с файлами, каталогами и URL-ами.

Во-первых, это многочисленные предопределённые переменные, которые описаны в документации и значения которых в своём скрипте можно посмотреть с помощью команды phpinfo() :

. when altering one's mind becomes as easy as programming a computer, what does it mean to be human.

10 сентября 2011 г.

Сериализация - общие сведения о файлах

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

Все файловые системы следуют одной и той же общей системе именования отдельных файлов: базовое имя файла ( MyFile ) и дополнительное расширение файла ( txt ), разделенные точкой. Базовое имя файла вместе с расширением файла называется именем файла: ( MyFile.txt ). Тем не менее, каждая файловая система (вроде NTFS, CDFS, ExFAT, UDF, FAT и FAT32) может иметь конкретные и иные правила формирования отдельных компонентов в пути к каталогу или файлу. Обратите внимание, что каталог (также называемый директорией ), предназначенный для упорядочивания файлов путём группировки, - это просто файл со специальным атрибутом, отмечающим его как каталог, но в остальном каталоги должны следовать всё тем же правилам именования, как и обычные файлы. Поскольку термин "каталог" просто ссылается на специальный тип файла, то некоторые справочные материалы используют общий термин "файл", чтобы охватить как понятия каталога, так и понятие файла данных как такового. Из-за этого, если не указано иное, любые имена и правила использования или примеры для файла применимы также и к каталогам. Каталог не следует путать с папкой. Папка - это более общее понятие. Каталог всегда физически представлен на диске, а папка может как быть каталогом, так и представлять виртуальное (логическое) размещение - к примеру, папка "Сетевое окружение" или "Мой компьютер". Каталог самого верхнего уровня на диске называется корневым. Корневой каталог всегда единственен, но у каждого диска он свой.

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

Термин "путь" ссылается на один или несколько каталогов (или папок), разделённых обратной косой чертой (\ - обратный слэш, бэкслэш, back-slash), и, возможно, на имя тома ( C: ) или имя сервера ( \\server , \\?\UNC\server или \\?\C: ). Примечание: в некоторых дальневосточных версиях Windows для разделителя пути используется иной символ, но надо понимать, что это ровно тот же символ (с тем же ANSI-кодом), просто он выглядит иначе.

  1. LFS (Local File System) - имена в локальной файловой системе, например: C:\MyFolder\MyFile.txt
  2. UNC (Uniform Naming Convention) - сетевые UNC-имена, например: \\server\MyFolder\MyFile.txt
  3. Long UNC или UNCW - длинные имена, например: \\?\UNC\server\MyFolder\MyFile.txt или \\?\C:\MyFolder\MyFile.txt

Один из каталогов на диске является активным для работающей программы. Он называется текущим каталогом. Текущий каталог всегда один, он задаётся при запуске программы и может меняться в процессе её работы (путём вызова функции смены каталога). Текущий каталог является активным, рабочим - он используется при разрешении имён (см. ниже). Кроме текущего каталога программы система также отдельно отслеживает текущий каталог каждого диска. Диск, указанный в текущем каталоге, называется текущим диском.

Путь, начинающийся с имени тома ( C:\MyFolder\MyFile.txt ), имени сервера ( \\server\MyFolder\MyFile.txt ) или корневого каталога ( \MyFolder\MyFile.txt ) называется абсолютным - потому что такое имя всегда однозначно указывает на один и тот же файл, вне зависимости от внешнего окружения. В противном случае путь называется относительным (вроде MyFile.txt , .\MyFile.txt , .\MyFolder\MyFile.txt или ..\..\MyFolder\MyFile.txt ). Относительные пути трактуются в зависимости от текущего каталога. Поэтому один и тот же относительный путь может ссылаться на разные файлы. К примеру, путь MyFile.txt и .\MyFile.txt ссылаются на C:\MyFolder\MyFile.txt , если текущий каталог (или каталог, относительно которого происходит разрешение имени) равен C:\MyFolder\ , но эти же имена будут ссылаться на D:\Program Files\MyFolder\MyFile.txt , если текущий каталог - D:\Program Files\MyFolder\ . Не следует путать полное имя файла с абсолютным. Это немного разные понятия, хотя часто их рассматривают как синонимы. Под полным именем файла понимается имя файла с путём - имя, по которому можно найти файл. Но оно не обязано быть абсолютным. С другой стороны, любое абсолютное имя всегда является полным именем. В английском языке используется термин "fully-qualified path" ("полностью указанный путь") - это синоним абсолютного пути файла.

Ограничения на количество символов также могут быть различны и меняться в зависимости от файловой системы и способа именования файла. Это осложняется ещё и поддержкой обратной совместимости. Например, старые файловые системы MS-DOS поддерживают максимум 8 символов для базового имени файла и 3 символа для расширения - в общей сложности 12 символов, включая точку-сепаратор. Кроме того, эти имена не могли включать в себя многие символы - к примеру, пробел. Этот формат имени файла широко известен как "формат файла 8.3" или короткое имя файла. Файловые системы Windows не имеют подобного ограничения, и хотя они поддерживают имена формата 8.3 для обратной совместимости, в основном они работают с длинными именами файлов.

Соглашения по именованию

  • Используйте точку для отделения базового имени файла от расширения в имени файла или каталога. Каталоги могут иметь расширение, хотя обычно оно не используется.
  • Используйте обратную косую черту (\) для разделения компонентов пути. Обратная косая черта разделяет имя файла от пути к нему, и имя одного каталога от другого каталога в пути. Вы не можете использовать обратную косую черту как часть имени реального файла или каталога, потому что это зарезервированный символ, который делит полное имя файла на компоненты.
  • Используйте обратную косую черту в соответствии с требованиями как часть имени тома, например, C:\ в C:\path\file или \\server\share в \\server\share\path\file .
  • Имена файлов не чувствительны к регистру. Например, имена OSCAR , Oscar и oscar ссылаются на один и тот же файл. Примечание: в целях совместимости с POSIX стандартом вы можете включить чувствительность к регистру для файловых имён, но это нестандартное поведение и оно не рекомендуется к использованию в общих сценариях.
  • Имена томов (буквы дисков) также не чувствительны к регистру. Например, D: и d: относятся к одному и тому же тому.
  • Вы можете использовать любой символ для имени файла, включая Unicode символы, за исключением следующих специальных символов:
    • < (меньше)
    • > (больше)
    • : (двоеточие)
    • " (двойные кавычки)
    • / (косая черта, слэш)
    • \ (обратная косая черта, обратный слэш)
    • | (вертикальная черта, труба)
    • ? (знак вопроса)
    • * (звёздочка)
    • Ноль (NUL-символ)
    • Символы, чьи коды лежат в диапазоне от 1 до 31 (за исключением альтернативных потоков данных, где эти символы допускаются)
    • Любые другие символы, который не поддерживает нижележащая файловая система

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

    Если какой-то компонент пути является именем файла, то он должен быть последним компонентом в пути.

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

    Абсолютные и относительные пути

    • UNC-имя любого формата, которое всегда начинается с двух бэк-слешей ( \\ ).
    • Обозначение диска с бэк-слешем, например: C:\ или D:\ .
    • Один обратный бэк-слеш, представляющий корневой каталог - например, \folder или \file.txt .
    • C:tmp.txt ссылается на файл с именем tmp.txt в текущем каталоге на диске С.
    • C:Temp\tmp.txt ссылается на файл tmp.txt в подпапке Temp текущего каталога диска С.
    • ..\tmp.txt указывает на файл с именем tmp.txt , расположенный в родительском каталоге текущего каталога.
    • ..\..\tmp.txt указывает на файл, находящийся на два каталога выше текущего каталога.
    • ..\Temp\tmp.txt указывает на файл с именем tmp.txt , находящийся в каталоге Temp , который в свою очередь находится в родительском каталоге текущего каталога.
    • C. \Temp\tmp.txt указывает на файл с именем tmp.txt , находящийся в каталоге Temp , который в свою очередь находится в родительском каталоге текущего каталога диска C.
    • C:\Temp\..\Temp\tmp.txt и C:\Temp\.\tmp.txt - эти два пути ссылаются на файл C:\Temp\tmp.txt . Хотя никто не будет задавать путь в таком виде, но подобные пути могут получаться после склейки полного пути из нескольких компонентов из разных источников. Хотя путь такого вида является абсолютным (не относительным) в смысле исходного определения, иногда его всё же называют относительным, подчёркивая наличие компонента .. в пути.

    Максимальное ограничение длины пути

    В Windows максимальная длина пути равна MAX_PATH символов, где MAX_PATH определена как константа, равная 260 - за некоторыми исключениями, обсуждаемыми ниже. Локальный путь состоит из следующей последовательности: буква диска, двоеточие, бэк-слеш, компоненты имени, разделённые бэк-слешами. Например, максимальный путь на диске D имеет вид D:\какие-то-256-символов-пути (и ещё один символ, до 260, занимает терминирующий ноль).

    В Windows также имеются функции, которые позволяют использовать расширенные пути файлов. Для таких путей ограничение на максимальную длину имени равно 32'767 символов. А каждый компонент в пути ограничен значением, зависящим от файловой системы - как правило, 255 символов. Подобные пути задаются (и трактуются) специальным образом. Для задания такого пути нужно использовать префикс \\?\ , например: \\?\D:\очень-длинный-путь или \\?\UNC\server\очень-длинный-путь .

    Подобные имена можно использовать только в Unicode-функциях Windows. К ним (именам) следует относиться с осторожностью по двум причинам. Во-первых, обычные программы не смогут получить доступ к файлам и каталогам, имена которых превысят типичное ограничение в MAX_PATH . Во-вторых, UNCW-имена передаются нижележащей файловой системе "как есть", минуя обычный слой нормализации путей. К примеру, / не будет заменён на \, имена .. (две точки) и . (одна точка) не будут являться специальными и не будут разворачиваться в реальные имена каталогов. Вот почему и появляется возможность задавать имена более 260 символов в пути (а также имена с именами, иначе считающимися недопустимыми - скажем, с точкой на конце) - потому что имена передаются файловой системе без обработки, так что слой нормализации не накладывает ограничение в 260 символов (и другие правила файловых имён Windows).

    Пространства имён

    Префикс имени файла определяет пространство имён, к которому принадлежит путь. Существуют две основные категории пространств имён, используемые в Windows API: пространства имён NT и пространств имён Win32. Пространство имён NT было разработано как пространство имён низкого уровня, корневым пространством имён, поверх которого могли бы существовать другие пространства имён - включая подсистему Win32 и, как следствие, пространство имён Win32. POSIX является еще одним примером подсистемы в Windows, которая построена поверх NT.

    Для исследования пространства имён вы можете использовать утилиту WinObj от SysInternals.

    Файловые пространства имён Win32

    К ним относятся имена, начинающиеся с \\?\ - мы уже разобрали их выше.

    Префиксы вида C:\ являются псевдонимами.

    Пространства имён устройств Win32

    Для доступа к устройствам вместо физических файлов используется пространство имён устройств. Для указания пути при этом используется префикс \\.\ (два бэк-слеша, точка, бэк-слеш). К примеру, так вы можете получить доступ к диску как физическому устройству, без обращения к файловой системе. Но, конечно же, "устройства" не ограничиваются только дисками.

    К примеру, если вы хотите открыть порт последовательной связи номер 1, то вы можете использовать имя COM1 в вызове функции CreateFile . Это работает, потому что COM1-COM9 являются частью зарезервированных имён в пространстве имён NT. Это работает как псевдоним на устройство, хотя вы можете и явно указывать префикс \\.\ . Для сравнения: если вдруг у вас есть сто COM-портов и вам надо обратиться к 56-му COM-порту, то вы не сможете открыть его по имени COM56 - потому что для него нет никакого предопределённого псевдонима или резервирования. Вам нужно будет открыть его по имени \\.\COM56 .

    Пространства имён NT

    Существуют также API функции, которые позволяют использовать именование в стиле NT, но в большинстве случаев это не нужно. Для наиболее востребованных объектов создаются ссылки (псевдонимы), чтобы к ним можно было получить доступ, используя обычные функции. К примеру, к пространству имён NT относятся такие вещи как Serial0 и Serial1 , HarddiskVolume1 и Harddisk0 , но обычно с ними работают через пространство имён Win32, используя такие имена как C: и \\.\PhysicalDrive0 .

    Как уже было сказано, другие пространства имён реализуются поверх пространства имён NT. К примеру, для реестра в корне создаётся элемент REGISTRY , объекты ядра находятся в KernelObjects , про устройства и файлы Win32 я уже говорил, тут же находятся и сессии и, скажем, глобальные и локальные имена объектов IPC и так далее.

    Напоминаю, что вы можете использовать утилиту WinObj для просмотра пространств имён.

    На этом я заканчиваю рассказ про файлы и перехожу к собственно сериализации данных.


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

    Имя файла может включать один или несколько из этих компонентов:

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

    СОДЕРЖАНИЕ

    История

    Точка (период или полная остановка) в качестве разделителя расширения имени файла, а также ограничение на три буквы расширение, появилась в 1970 - х годах. Они могли исходить из 16-битных ограничений кодировки символов RAD50 .

    Традиционно большинство операционных систем поддерживало имена файлов только с прописными буквенно-цифровыми символами, но со временем количество допустимых символов увеличивалось. Это приводило к проблемам совместимости при перемещении файлов между разными файловыми системами.

    В 1985 году RFC 959 официально определил имя пути как строку символов, которая должна быть введена в файловую систему пользователем для идентификации файла.

    Примерно в 1995 году VFAT , расширение файловой системы MS-DOS FAT, было представлено в Windows 95 и Windows NT . Это позволило использовать длинные имена файлов Unicode (LFN) в смешанном регистре в дополнение к классическим именам «8.3».

    Ссылки: абсолютные vs относительные

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

    Таким образом, абсолютный или относительный путь состоит из последовательности имен файлов.

    Количество имен в файле

    Unix-подобные файловые системы позволяют файлу иметь более одного имени; в традиционных файловых системах в стиле Unix имена являются жесткими ссылками на индексный дескриптор файла или его эквивалент. Windows поддерживает жесткие ссылки в файловых системах NTFS и предоставляет команды для их создания fsutil в Windows XP и mklink более поздних версиях. Жесткие ссылки отличаются от ярлыков Windows , классических псевдонимов Mac OS / macOS или символических ссылок . Введение LFN с VFAT позволило использовать псевдонимы файлов. Например, в псевдониме имени файла было максимум восемь плюс три символа, чтобы соответствовать ограничениям 8.3 для старых программ. longfi

    1. long file name.

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

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

    Ограничения по длине

    Особая проблема с файловыми системами, которые хранят информацию во вложенных каталогах, заключается в том, что можно создать файл с полным путем, превышающим ограничения реализации, поскольку проверка длины может применяться только к отдельным частям имени, а не ко всему имени. Многие приложения Windows ограничены MAX_PATH значением 260, но имена файлов Windows могут легко превысить это ограничение [2] . В Windows 10 версии 1607 ограничения MAX_PATH были сняты.

    Расширения имени файла

    Многие файловые системы, включая системы FAT , NTFS и VMS , рассматривают как расширение имени файла часть имени файла, которая состоит из одного или нескольких символов, следующих за последней точкой в ​​имени файла, разделяя имя файла на две части: базовое имя или основу а также расширение или суффикс, используемый некоторыми приложениями для обозначения типа файла . Несколько выходных файлов, созданных приложением, используют одно и то же базовое имя и разные расширения. Например, компилятор может использовать расширение FOR для исходного входного файла (для кода Fortran), OBJ для вывода объекта и LST для листинга. Хотя есть несколько распространенных расширений, они произвольны, и другое приложение может использовать REL и RPT . Расширения были ограничены, по крайней мере исторически в некоторых системах, длиной до 3 символов, но в целом могут иметь любую длину, например html .

    Совместимость кодирования

    Не существует общего стандарта кодировки для имен файлов.

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

    Совместимость индикации кодирования

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

    Имя файла может быть сохранено с использованием разных байтовых строк в разных системах в пределах одной страны, например, если в одной из них используется японская кодировка Shift JIS и другая японская кодировка EUC . Преобразование было невозможно, поскольку большинство систем не отображало описание кодировки, используемой для имени файла, как часть расширенной информации о файле. Это заставляло дорогостоящее угадывать кодировку имени файла при каждом доступе к файлу.

    Решением было принять Unicode в качестве кодировки имен файлов.

    Однако в классической Mac OS кодировка имени файла сохранялась с атрибутами имени файла.

    Совместимость Unicode

    Стандарт Unicode решает проблему определения кодировки.

    Тем не менее, остаются некоторые ограниченные проблемы совместимости, такие как нормализация (эквивалентность) или используемая версия Unicode. Например, UDF ограничен Unicode 2.0; В файловой системе MacOS HFS + применяется нормализация NFD Unicode и, при необходимости, учитывается регистр (по умолчанию регистр не учитывается). Максимальная длина имени файла нестандартна и может зависеть от размера единицы кода. Хотя это серьезная проблема, в большинстве случаев она носит ограниченный характер.

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

    Проблема эквивалентности Unicode известна как «коллизия нормализованных имен». Решением является ненормализующая осведомленность о композиции Unicode, используемая в технических сообществах Subversion и Apache. Это решение не нормализует пути в репозитории. Пути нормализованы только для сравнения. Тем не менее, некоторые сообщества запатентовали эту стратегию, запрещая ее использование другими сообществами.

    Перспективы

    Чтобы ограничить проблемы взаимодействия, некоторые идеи, описанные Sun, заключаются в следующем:

    • используйте одну кодировку Unicode (например, UTF-8)
    • делать прозрачные преобразования кода для имен файлов
    • не хранить нормализованные имена файлов
    • проверьте каноническую эквивалентность между именами файлов, чтобы избежать двух канонически эквивалентных имен файлов в одном каталоге.

    Эти соображения создают ограничение, не позволяющее переключиться на будущую кодировку, отличную от UTF-8.

    Миграция Unicode

    Одна из проблем заключалась в переходе на Unicode. С этой целью несколько компаний-разработчиков программного обеспечения предоставили программное обеспечение для перевода имен файлов в новую кодировку Unicode.

    • Microsoft предоставила прозрачную для пользователя миграцию в рамках технологии VFAT.
    • Apple предоставила «Утилиту восстановления кодировки имен файлов v1.0».
    • Сообщество Linux предоставило « convmv ».

    Mac OS X 10.3 ознаменовала принятие Apple декомпозиции символов Unicode 3.2, которая заменила использовавшуюся ранее декомпозицию Unicode 2.1. Это изменение вызвало проблемы у разработчиков, пишущих программное обеспечение для Mac OS X.

    Уникальность

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

    Подход уникальности может отличаться как от чувствительности к регистру, так и от формы нормализации Unicode, такой как NFC, NFD. Это означает, что могут быть созданы два отдельных файла с одним и тем же текстовым именем файла и разной байтовой реализацией имени файла, например L "\ x00C0.txt" (UTF-16, NFC) (латинская заглавная A с могилой) и L "\ x0041 \ x0300.txt "(UTF-16, NFD) (латинская заглавная A, объединение могил).

    Сохранение регистра букв

    Некоторые файловые системы, такие как FAT , хранят имена файлов в верхнем регистре независимо от регистра букв, использованных для их создания. Например, файл, созданный с именем «MyName.Txt» или «myname.txt», будет сохранен с именем «MYNAME.TXT». Для обозначения одного и того же файла можно использовать любые вариации верхнего и нижнего регистра. Такие файловые системы называются нечувствительными к регистру и не сохраняют регистр . Некоторые файловые системы вообще запрещают использование строчных букв в именах файлов.

    Некоторые файловые системы хранят имена файлов в том виде, в котором они были изначально созданы; они называются « сохраняющими дело» или « сохраняющими дело» . Такая файловая система может быть чувствительной к регистру или нечувствительной к регистру . Если учитывается регистр, то «MyName.Txt» и «myname.txt» могут относиться к двум разным файлам в одном и том же каталоге, и для ссылки на каждый файл необходимо использовать заглавные буквы, которыми он назван. С другой стороны, в файловой системе без учета регистра и сохранении регистра только одно из «MyName.Txt», «myname.txt» и «Myname.TXT» может быть именем файла в заданном каталоге в заданное время, и на файл с одним из этих имен можно ссылаться, используя любую заглавную букву имени.

    С самого начала Unix и производные от нее системы сохраняли регистр. Однако не все Unix-подобные файловые системы чувствительны к регистру; по умолчанию HFS + в macOS нечувствителен к регистру, а серверы SMB обычно обеспечивают нечувствительность к регистру (даже если базовая файловая система чувствительна к регистру, например Samba в большинстве Unix-подобных систем), а клиентские файловые системы SMB обеспечивают регистр - бесчувственное поведение. Чувствительность к регистру файловой системы является серьезной проблемой для таких программ, как Samba и Wine , которые должны эффективно взаимодействовать с обеими системами, которые обрабатывают файлы в верхнем и нижнем регистре как разные, и с системами, которые обрабатывают их одинаково.

    Зарезервированные символы и слова

    «Зарезервированные символы» перенаправляются сюда. О символах, которые нельзя использовать в заголовках страниц в Википедии, см. Википедия: Соглашения об именах (технические ограничения) § Запрещенные символы .

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

    Многие утилиты файловой системы запрещают использование управляющих символов в именах файлов. В Unix-подобных файловых системах нулевой символ и разделитель пути / запрещены.

    В Windows

    Утилиты файловой системы и соглашения об именах в различных системах запрещают использование определенных символов в именах файлов или делают их проблемными:

    five\ and\ six\<seven (пример экранирования)
    'five and six<seven' или "five and six<seven" (примеры цитирования)

    Символ å ( 0xE5 ) не разрешался в качестве первой буквы в имени файла в 86-DOS и MS-DOS / PC DOS 1.x-2.x, но может использоваться в более поздних версиях.

    В утилитах Windows нельзя использовать пробел и точку в качестве последнего символа имени файла. Точка разрешена в качестве первого символа, но некоторые приложения Windows, такие как Windows Explorer , запрещают создание или переименование таких файлов (несмотря на то, что это соглашение используется в Unix-подобных системах для описания скрытых файлов и каталогов). Обходные пути включают добавление точки при переименовании файла (которая затем автоматически удаляется), использование альтернативных файловых менеджеров , создание файла с помощью командной строки или сохранение файла с желаемым именем файла из приложения.

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

    В Unix-подобных системах, DOS и Windows имена файлов "." и ".." имеют особое значение (текущий и родительский каталог соответственно). Windows 95/98 / ME также использует такие имена, как «. », «. » и т. Д. Для обозначения каталогов прародителей или прародителей. Все версии Windows запрещают создание имен файлов, состоящих только из точек, хотя имена, состоящие из трех точек («. ») или более, допустимы в Unix.

    Кроме того, в утилитах Windows и DOS некоторые слова также зарезервированы и не могут использоваться в качестве имен файлов. Например, файлы устройств DOS :

    Системы с этими ограничениями вызывают несовместимость с некоторыми другими файловыми системами. Например, Windows не сможет обработать или создать отчеты об ошибках для этих допустимых имен файлов UNIX: aux.c, q "uote" s.txt или NUL.txt.

    Имена файлов NTFS, которые используются для внутреннего использования, включают:

    Сравнение ограничений имени файла

    Запрещает использование символов в диапазоне 1-31 (0x01-0x1F) и символов "* /: <>? \ |, Если имя не помечено как находящееся в пространстве имен Posix. NTFS позволяет каждому компоненту пути (каталог или имя файла) быть Длина 255 символов.

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

    Из предыдущего опыта работы с вычислительной техникой вы уже имеете некоторое представление о файле, как об именованном наборе данных, хранящемся где-нибудь на магнитных дисках или лентах. Для нашего сегодняшнего обсуждения нам достаточно такого понимания, чтобы разобраться в том, как организована работа с файлами в операционной системе UNIX . Более подробное рассмотрение понятия " файл " и организации файловых систем для операционных систем в целом будет приведено в лекции 11 и лекции 12, а также на семинарах 11–12, посвященных организации файловых систем в UNIX .

    Все файлы, доступные в операционной системе UNIX , как и в уже известных вам операционных системах, объединяются в древовидную логическую структуру. Файлы могут объединяться в каталоги или директории. Не существует файлов, которые не входили бы в состав какой-либо директории. Директории в свою очередь могут входить в состав других директорий. Допускается существование пустых директорий, в которые не входит ни один файл , и ни одна другая директория (см. рис. 1–2.1). Среди всех директорий существует только одна директория , которая не входит в состав других директорий – ее принято называть корневой. На настоящем уровне нашего незнания UNIX мы можем заключить, что в файловой системе UNIX присутствует, по крайней мере, два типа файлов: обычные файлы, которые могут содержать тексты программ, исполняемый код , данные и т.д. – их принято называть регулярными файлами, и директории.

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

    • Нельзя создавать имена большей длины, чем это предусмотрено операционной системой (для Linux – 255 символов).
    • Нельзя использовать символ NUL (не путать с указателем NULL !) – он же символ с нулевым кодом, он же признак конца строки в языке C.
    • Нельзя использовать символ '/' .

    От себя добавим, что также нежелательно применять символы "звездочка" – "*" , "знак вопроса" – "?" , "кавычка" – "\"" , " апостроф " – "\`" , " пробел " – " " и " обратный слэш" – "\\" (символы записаны в нотации символьных констант языка C).

    Единственным исключением является корневая директория , которая всегда имеет имя "/" . Эта же директория по вполне понятным причинам представляет собой единственный файл , который должен иметь уникальное имя во всей файловой системе. Для всех остальных файлов имена должны быть уникальными только в рамках той директории, в которую они непосредственно входят. Каким же образом отличить два файла с именами "aaa.c" , входящими в директории "b" и "d" на рисунке 1–2.1, чтобы было понятно о каком из них идет речь? Здесь на помощь приходит понятие полного имени файла .

    Давайте мысленно построим путь от корневой вершины дерева файлов к интересующему нас файлу и выпишем все имена файлов (т.е. узлов дерева), встречающиеся на нашем пути, например, "/ usr b aaa.c" . В этой последовательности первым будет всегда стоять имя корневой директории, а последним – имя интересующего нас файла. Отделим имена узлов друг от друга в этой записи не пробелами, а символами "/" , за исключением имени корневой директории и следующего за ним имени ( "/usr/b/aaa.c" ). Полученная запись однозначно идентифицирует файл во всей логической конструкции файловой системы. Такая запись и получила название полного имени файла .

    Понятие о текущей директории. Команда pwd. Относительные имена файлов

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

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

    Читайте также: