Пути (продолжение)

Персональный блог одноименного форумчанина. Человека и парохода, не побоюсь этого сравнения :)

Модератор: tyomitch

tyomitch
Пользователь #1352
Пользователь #1352
Аватара пользователя
 
Сообщения: 12822
Зарегистрирован: 20.10.2002 (Вс) 17:02
Откуда: חיפה

Пути (продолжение)

Сообщение tyomitch » 11.07.2006 (Вт) 5:30

* В прошлый раз я успел дойти до MS-DOS/FAT. В 16-битных Windows работа с диском полностью отдавалась на откуп подлежащему досу; разве что в Windows 3.11 появилась возможность поставить дисковые драйвера защищённого режима, которые позволяли обращаться к диску в 32-битном режиме. (Это цитата из какого-то рекламного проспекта; я не знаю, что такое "32-битный режим обращений к диску".) Поддержка файловых систем полностью определялась установленными драйверами; существуют драйверы от третьих фирм, позволяющие добавить в Windows 3.11 поддержку FAT32 заодно с длинными именами.

Длинные имена появились в 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. Далее, далеко не все юниксовые программы умеют работать с вилками -- даже скопировать файл, не потеряв ресурсы, для них проблема. В общем, имхо проведён классический эксперимент по скрещиванию ужа с ежом :-)
Последний раз редактировалось tyomitch 15.07.2006 (Сб) 10:54, всего редактировалось 2 раз(а).
Изображение

tyomitch
Пользователь #1352
Пользователь #1352
Аватара пользователя
 
Сообщения: 12822
Зарегистрирован: 20.10.2002 (Вс) 17:02
Откуда: חיפה

Сообщение tyomitch » 15.07.2006 (Сб) 10:38

Ещё хочу дописать про UNC-пути в Windows: в форме \\servername\sharename\subdir. Windows NT позволяет передавать длинные пути под видом UNC-путей, где в качестве имени сервера стоит ?. Если же в качестве имени сервера стоит ., то это имя проецируется во внутренний путь \??, где лежат симлинки на все доступные из Win32 устройства: кроме обычных именованных дисков, там есть безымянные диски, почти все физические устройства, а также "псевдоустройства", представляющие именованные трубы и мейлслоты. Там есть (под именем \??\NUL) даже симлинк на горячо любимое юниксоидами псевдоустройство \Device\Null :-)

Всё это, насколько я понимаю, реализуется какой-то навороченной системой сетевых редиректоров (точно так же подключались FAT32-диски в Windows 3.11).

К слову: все остальные именованные объекты Win32 (мутексы, события, семафоры, файлмаппинги) лежат в одной куче в \BaseNamedObjects; в отличие от них, имена труб и мейлслотов представляются как пути в "виртуальных файловых системах" Npfs и Msfs, соответственно.
Изображение

Денис Победря
Мегобойанист
Мегобойанист
 
Сообщения: 1037
Зарегистрирован: 03.01.2005 (Пн) 21:29
Откуда: Из Москвы

Сообщение Денис Победря » 15.07.2006 (Сб) 15:42

А интересно то всё таки.
[Место cдаётся]


Вернуться в Tyomitch

Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 0

    TopList