MERCURY127
Platinum Member | Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
Все, что вы хотели знать о доступе к локальным томам NTFS из под систем 9х, но боялись спросить...
Изначально семейство 9х не поддерживает NTFS ни в какой форме, кроме доступа через сеть. Т.е. NTFS том должен быть расшарен по сети какой то другой системой, уже имеющей родную поддержку NTFS. Ситуация полностью аналогична тому, что семейство NT 3.x/4.0 не имеет родной поддерки FAT32. Однако если в NT проблема решается написанием одного единственного драйвера уровня ядра, после чего система способна даже грузиться с томов FAT32, то с 9х все намного сложнее...
Семейство 9х фактически трехслойное: слой ядра реального режима (известный как самостоятельная подсистема текстового режима - DOS 7.x), слой ядра защищенного режима (VMM.VXD и все с ним связанное), слой оболочки и прикладных программ (.EXE, .DLL и пр.).
Для запуска первого слоя, т.е. ДОС, с NTFS тома решений не найдено.
После загрузки ДОС с чего быто ни было, уже имеется возможность подключения томов NTFS. Для этого использутся драйверы NTFSDOS, NTFSREAD (R/O), NTFSPRO (R/W). После загрузки этих драйверов можно обрацаться к NTFS томам, как к обычным логическим дискам. Можно даже выполнять проверку этих дисков утилитой NTFSCHK... Этих драйверов обычно достаточно и для запуска второго слоя системы - ядра защищенного режима, но вот доступ к таким томам будет "в режиме MS-DOS", т.е. 16-ибитным.
Для работы системы с NTFS на уровне третьего слоя достаточно загрузить (скопировать в \windows\system\iosubsys\) сторонний драйвер pntfs.vxd производства Paragon (т.е. нет нужды использовать драйвера второго слоя). После этого ВСЕ локальные NTFS тома, включая находящиеся на сьемных носителях (флешки), становятся доступными на чтение/запись (впрочем, есть версия драйвера только на чтение). Однако само устройство 9х вносит жесткие ограничения, не характерные для самой NTFS:
1) 9х не поддерживает файлы более 4 GiB (максимальный адрес читаемого байта равен 4 294 967 293 = 0xFFFFFFFDh, или 4 GiB -2 байта), т.к. на системах FAT больших файлов и быть не может. Поэтому при разработке в ядро 9х закладывался 32-хбитный счетчик позиционирования внутри файлов, хотя соответствующие функции Win32 ДОПУСКАЛИ 64-хбитный счетчик. Эта переменная фигурирует во множестве файлов ядра, и увеличение ее разрядности невозможнол без перекомпиляции как минимум всего ядра.
На NTFS могут быть файлы размером более 4 GiB, т.к. там 64-хбитный счетчик. При чтении таких файлов под 9х их размер будет маскироваться 32-хбитным счетчиком, вследствии чего ВСЕ операции с файлом будут воздействовать лишь на первые 4 GiB файла.
Все, имеющее размер более 32 бит, теряет старшие биты. Т.е. операции ведутся "по модулю" 32 бита. Это значит, что:
из 4 Гб - 2 байта - доступно все;
из 4 <= Х <= 8 Гб - доступны первые Х-4 Гб;
из 8 <= Х <= 12 Гб - доступны первые Х-8 Гб, и т.д.
Т.е. из файла размером 0x100000001h = 4 294 967 297, а также 0x200000001h, 0x300000001h и т.д. байтов, доступен лишь первый байт.
2) Семейство NT "бережет" свою родную файловую систему, в полной мере используя ее фишки типа разграничения доступа, аудита, протоколирования, журналирования. В частности, перед копированием файла NT делает специальные пометки, снимаемые лишь после успешного окончания операции. В случае неуспеха последствия для системы оказываются минимальными.
3) NTFS имеет встроенные механизмы разграничения прав доступа к файлам, сохраняющиеся даже при переносе всего диска в другую машину. Но эти механизмы работают только в NT системах.
Т.к. на FAT ничего лучше "меток грязного тома" придумать не удалось, 9х мало заботиться о сохранности данных. И уж совершенно ничего не знает о правах доступа и журналировании. Это имеет две стороны:
9х, получив доступ к томам NTFS, не обращает никакого внимания на ограничения доступа к файлам (полный доступ в т.ч. к реестру NT и служебным файлам NTFS);
9х, не умея журналировать файловые операции, снижает надежность NTFS до уровня самой себя...
И это лишь небольшой список возможных проблем...
4) NTFS умеет наряду с основым содержимым (потоком данных) файла хранить так называемые "альтернативные потоки" (http://habrahabr.ru/blogs/windows/46935), привязанные к файлу, но независимые от основного потока. Но эти механизмы работают только в NT системах, команда "more < file:stream" под 98 НЕ работают, по крайней мере, с pntfs.vxd.
Более полная информация и точная информация о NTFS здесь http://www.ixbt.com/storage/ntfs.html |
Сеть тоже наверно отсутствует как класс... Кстати вспомнил, на старой инсталляции sharing межу 98-м и вистой работал только со стороны висты, правда в обе стороны. 98-й при попытке обращения к шарам висты вис намертво. На свежей инсталляции не пробовал. 
Сам писал что-то для CAMAC-а под дос, когда у нас планировали ускоритель строить. 
...
! А я ведь говорил - не злоупотребляйте фишкой RW 
!!! Хотя я лично проверял - все было окей.... 
...