Длинные имена появились в Windows 95/MS-DOS 7.0/VFAT: они дробятся на блоки по 13 юникодных символов, и каждый такой блок записывается в каталог как отдельный файл с атрибутами "VSHR". Вопреки распространённому заблуждению, длинные имена не требуют FAT32, поддержка которого появилась начиная с Win95 OSR2/MS-DOS 7.1. (В ветке NT поддержка VFAT и FAT32 добавилась, соответственно, в WinNT 3.5 и Win2000.) Файлы с длинными именами можно создавать даже на флоппиках, где FAT12.
Ограничения на длину пути в Windows уже кем-то постились: 255 на каждое имя, и 260 на весь путь целиком. Использование Юникода позволяет вставлять в названия файлов практически любые символы, хотя файлы с чересчур необычными символами в названии можно открывать только юникодными API. Регистр в именах сохраняется, но не учитывается; приведение имён к регистро-независимой форме при поиске в каталоге учитывает региональные настройки компьютера, так что их изменение позволяет создавать на диске нечитаемые файлы
* В Windows NT и его NTFS всё интереснее. Два бита, остававшихся свободными в байте атрибутов, получили назначения "сжатый" и "шифрованный". Появилась возможность хардлинков -- создания файлов, одновременно доступных под несколькими равноправными именами, -- и симлинков на каталоги и тома. Теперь любой том или каталог можно подключить как подкаталог любого другого каталога; это позволяет иметь один логический диск, и подключить все физические диски в его каталоги -- тогда, как в Unix, получится строго иерархическая файловая система.
В Windows NT можно при желании включить различение регистров в именах файлов, передавая в CreateFile флаг FILE_FLAG_POSIX_SEMANTICS. Ограничение длины имени -- 255 символов. Другой любопытный факт -- то, что NTFS позволяет использовать в именах файлов абсолютно любые символы (включая \0); средствами WinAPI такой файл, ясное дело, будет недоступен. Таким способом маскируются всякие руткиты.
Ещё NTFS поддерживает стримы, доступ к каждому из которых возможен как к отдельному файлу. Имя стрима отделяется от имени файла двоеточием: например, \WINNT\system32\ntoskrnl.exe::$DATA. Стрим с именем :$DATA -- это собственно содержимое файла. Так как длина дополнительных стримов не включается в отображаемую в каталоге длину файла, и найти в них данные, на зная заранее, что они там есть, -- достаточно затруднительно, то в них тоже любит прятаться всякая нечисть
Самая интересная система путей зарыта внутри Windows NT, и используется его драйверами. Она строго иерархическая, и в неё подключены все именованные объекты в системе -- драйвера, трубы, мутексы и т.д. -- точно так же, как в Unix. (Оказывается, в WinNT можно создавать именованные процессы; но эта возможность не отражена в Win32API, и потому не используется.) Эта внутренняя система путей пронизана симлинками; так, мой системный каталог, на который указывает симлинк \SystemRoot, имеет путь \Device\Harddisk0\Partition8\WINNT. Ещё к нему можно обратиться по пути \DosDevices\H:\WINNT, где \DosDevices -- симлинк на \??, а \??\H:, как и \Device\Harddisk0\Partition8, -- симлинк на \Device\HarddiskVolume3. Значит, "истинный путь" моего системного каталога -- \Device\HarddiskVolume3\WINNT. При каждом обращении к именованым объектам, например файлам, WinNT проходит всю эту цепочку симлинков.
(добавлено позже: Кроме уже названных путей, на мой системный каталог указывает \ArcName\multi(0)disk(0)rdisk(0)partition(8)\WINNT. Именно симлинками в \ArcName WinNT пользуется при загрузке; кроме дисковых разделов, там есть неожиданный симлинк \ArcName\multi(0)disk(0)fdisk(0), указывающий на \Device\Floppy0 -- так что если захотите добавить в загрузочное меню WinNT загрузку с флопика, вы теперь знаете, что нужно дописать в boot.ini
)
* Ещё пара версий Windows, про которые я почти ничего не знаю -- это Windows CE и Vista. В WinCE, насколько я смог понять, дисков нет совсем, и устройства хранения подключаются в каталоги "основной" файловой системы; получающиеся бездисковые имена имеют вид \Windows\coredll.dll
В Висте, в свою очередь, обещают добавить одновременное сохранение нескольких версий каждого файла -- как в описанной в прошлом посте VMS. Такая фича уже есть в Win2003, но в "настольных" ОС её до сих пор не было.
* Последнее семейство ОС, которое хотелось бы рассмотреть -- это MacOS Classic, т.е. до версии 9.2. Начиная с 2.1 (а это 1985 г., т.е. одновременно с выходом Windows 1.0), использовалась HFS с рядом интересных особенностей. Прежде всего, каждому файлу соответствовало две "вилки" -- data fork с собственно содержимым файла, и resource fork с "нагрузкой" вроде иконок. Такая особенность MacOS доставляла её пользователям много хлопот при обмене данными: чтобы скопировать файл с/на обычный писючный флопик, или с/на сетевую шару, или послать/скачать его по Интернету -- приходилось его архивировать специальной прогой, которая объединяет обе вилки в одну. (Причём в составе MacOS такой проги не было.) В серверных ОС от Microsoft (до версии 2000 Server включительно) присутствовала служба Services For Macintosh, которая позволяла создать сетевую шару, видимую в MacOS как родную. В этом случае resource fork записывалась в отдельный стрим на NTFS-разделе сервера. Аналогичные решения третьих фирм, открытые и коммерческие, предпочитали записывать resource fork в отдельный невидимый файл -- так сложнее его незаметно потерять, сархивировав раздел тулзой, не поддерживающей дополнительные стримы.
Пути разделяются двоеточием, начиная с имени (метки) диска: disk name:dir name:file name; в имени файла двоеточие не допускается. Отдельные компоненты пути можно опускать; как и в MS-DOS, поддерживаются текущий диск и текущий каталог. Полный путь на текущем диске начинается с двоеточия.
Атрибуты включают защиту от записи, метку "файл/каталог" и мириады других, предназначенных исключительно для оболочки Finder -- включая цветную пометку и произвольный текстовый комментарий. "Фишкой" HFS является хранение всех файлов в одном списке-каталоге; при этом в записи каждого файла содержится указатель на его настоящий родительский каталог.
Особое значение имеет папка :System Folder: указатель на неё сохраняется где-то в загрузочном секторе диска. Перенос системы с одного диска на другой выполняется простым копированием этой папки: система, знающая об её особом статусе, сама произведёт все остальные необходимые действия, типа установки на диск своего загрузчика. Есть несколько других особых файлов -- в их числе файл обоев, файл рабочего стола с иконками и т.д. В отличие от Windows, разбрасывающей свои системные файлы по всему диску, все системные файлы MacOS Classic лежат именно в System Folder.
Вместо расширений, как в MS-DOS/Windows, для ассоциации приложений с файлами используется пара четырёхбайтовых Type ID/Creator ID в составе атрибутов файла; Creator ID соответствует ассоциированному приложению, а Type ID может использоваться для фильтрации файлов при открытии. Например, PDF-файлам соответствуют Creator ID "CARO" и TypeID "PDF ". Иконка, отображаемая для файла, зависит от его Creator ID.
* Что именно сделали с файловой системой в MacOS X, я не знаю; но видимо, там всё переделали. Для совместимости с Unix, пути разделяются слешами -- но по-прежнему в именах не учитывается регистр, как в Windows. Далее, далеко не все юниксовые программы умеют работать с вилками -- даже скопировать файл, не потеряв ресурсы, для них проблема. В общем, имхо проведён классический эксперимент по скрещиванию ужа с ежом
