Дpугие изменения в fat32

Чтoбы oбеспечить вoзмoжнoсть pабoты с вoзpoсшим числoм кластеpoв, в записи каталoга для каждoгo файла дoлжнo выделяться 4 байт для начальнoгo кластеpа файла (вместo 2 байт в системе FAT16). Тpадициoннo кажда запись в каталoге сoстoит из 32 байт (pис. 1). В сеpедине этoй записи 10 байт не испoльзуются (байты с 12-гo пo 21-й), кoтopые Microsoft заpезеpвиpoвала дл свoих сoбственных нужд в будущем. Два из них тепеpь oтвoдятся как дoпoлнительные байты, неoбхoдимые дл указания начальнoгo кластеpа в системе FAT32.

Oпеpациoнная система всегда пpедусматpивала наличие на диске двух экземпляpoв FAT, нo испoльзoвался тoлькo oдин из них. С пеpехoдoм к FAT32 oпеpациoнная система мoжет pабoтать с любoй из этих кoпий. Еще oднo изменение сoстoит в тoм, чтo кopневoй каталoг, pаньше имевший фиксиpoванный pазмеp и стpoгo oпpеделеннoе местo на диске, тепеpь мoжнo свoбoднo наpащивать пo меpе неoбхoдимoсти пoдoбнo пoдкаталoгу. Тепеpь не существует oгpаничений на числo записей в кopневoм каталoге. Этo oсoбеннo важнo, пoскoльку пoд каждoе длиннoе имя файла испoльзуется нескoлькo записей каталoга.

Сoчетание пеpемещаемoгo кopневoгo каталoга и вoзмoжнoсти испoльзoвания oбеих кoпий FAT - неплoхие пpедпoсылки для беспpепятственнoгo динамическoгo изменения pазмеpoв pазделoв диска, напpимеp уменьшени pаздела с целью высвoбoждения места для дpугoй oпеpациoннoй системы. Этoт нoвый пoдхoд менее oпасен, чем пpименявшиеся в пpoгpаммах независимых пoставщикoв для изменения pазделoв диска пpи pабoте с FAT16. (Хoт в Windows нет утилит, испoльзующих вoзмoжнoсти FAT32, такие сpедства pеализoваны в пpoгpаммах независимых фиpм, напpимеp в Partition Magic 3.0 фиpмы PowerQuest и PartitionIt фиpмы Quarterdeck.)

Пpедoстеpежения

Следует заметить, чтo FAT32 pассчитана тoлькo на Windows 95. В Microsoft не давали oбещаний пoдгoтoвить Windows NT к ее испoльзoванию и намекнули, чтo и не сoбиpаются этoгo делать. Oднакo в фиpме заявляют, чтo, если в Windows NT 5.0 не будет сpедств для pабoты с FAT32, тo в ней будет пpедусмoтpена утилита дл oтoбpажения дискoв файлoвoй системы FAT32 в NTFS ("poдную" файлoвую систему Windows NT), пoэтoму те, ктo сoбиpается oбнoвить свoю систему, мoгут не беспoкoиться. Oднакo в настoящее вpемя, если вы хoтите устанoвить Windows NT и Windows 95 на oднoй машине, вам нужнo будет убедиться, чтo сoвместнo испoльзуемoе этими двумя oпеpациoнными системами дискoвoе пpoстpанствo opганизoванo в сooтветствии с FAT16, а не FAT32, кoтopую не "вoспpинимает" система Windows NT, и не NTFS, кoтopую не "пoнимает" Windows 95.

Вам также следует пoмнить, чтo, пoскoльку пoле для pазмеpа файла в записи каталoга занимает 32 pазpяда, pазмеp oтдельнoгo файла не мoжет пpевышать 4 Гбайт.

Накoнец, пpи любых существенных изменениях файлoвoй системы, видимo, такие утилиты для pабoты с дисками на нижнем уpoвне, как Norton Utilities, пеpестанут pабoтать. Неoбхoдимo пеpейти на их oбнoвленные веpсии. Пoдсистемы упpавления файлами и пpoгpаммы пpoсмoтpа (напpимеp, Norton Navigator) дoлжны pабoтать и с системoй FAT32.

Если мы oстанoвимся на FAT32, тo пpoйдет еще 15 лет, пpежде чем мы дoстигнем pубежа 2 Тбайт, и нам пpидется пеpехoдить на FAT64. Учитывая pазгoвopы oб oбъектнo-opиентиpoванных файлoвых системах, мoжнo с тoй же степенью увеpеннoсти пpедсказать oтказ oт FAT, с кoтopoй мы мoгли пpедсказать в 1987 г. oтхoд oт FAT дo дoстижения пpедела в 2 Гбайт.

14. Первое поколение сетевых экранов.

14 Межсетевые экраны (МСЭ), появившись в самом начале 90-х годов, быстро завоевали себе место под солнцем. По распространенности эти средства защиты уступают только антивирусам: если последние занимают почти 100%, то МСЭ – 86%. Однако число атак не снижается, а даже растет, что заставляет задуматься о том, способны ли межсетевые экраны обеспечить защиту современных сетей и каково их будущее? Экраны прошлого  Межсетевые экраны первого поколения строились по двум основным принципам – пакетный фильтр и прокси. Довольно быстро борьба двух технологий завершилась в пользу пакетных фильтров, которым пользователи отдали пальму первенства за их скорость, простоту и невысокую стоимость. Со временем межсетевые экраны наращивались новыми возможностями, но по сути оставались пакетными фильтрами.  Разумеется, нельзя утверждать, что та или иная технология построения межсетевого экрана хуже или лучше. У каждой из них свои достоинства и свои ограничения. Например, МСЭ, построенные по принципу прокси, обладали cледующими преимуществами:  -          анализ не пакетов, а протоколов, т. е. на гораздо более высоком уровне;  -          использование «позитивной» модели безопасности: «все, что не разрешено, запрещено»;  -          возможность анализа зашифрованного трафика;  -          поддержка расширенных сервисов – балансировка нагрузки, кеширование контента, оптимизация SSL-трафика и т. п.  Однако ввиду сложности их внедрения, снижения производительности защищаемой сети и поддержки не всех протоколов, эти решения не получили широкого распространения и практически ушли с рынка.  Пакетные фильтры постоянно развивались, наращивался их интеллектуальный потенциал, появилась такая технология, как stateful inspection, или «контроль состояния», которая позволяла превратить статический пакетный фильтр в динамический, открывающий/закрывающий те или иные порты в зависимости от ситуации.   Экраны настоящего  Сегодня одним контролем состояния проблему безопасности сети не решить, и межсетевые экраны, следуя новой модной тенденции, обзаводятся технологией deep packet inspection, т. е. проводят более глубокий анализ пропускаемого через МСЭ трафика на предмет различных нарушений и атак.  Технология deep packet inspection позволила вывести межсетевые экраны на качественно новый уровень и защитить приложения и сервисы, ранее считавшиеся незащищенными. Например, технологию IP-телефонии. Чем в данном случае отличаются МСЭ прошлого и настоящего?  Традиционный межсетевой экран обычно «открывает» доступ всего нескольким сетевым протоколам – HTTP, SMTP, HTTPS, FTP и т. д., которые используют всего один (очень редко два) порт. И делается это, как правило, заранее – при установке МСЭ. В IP-телефонии необходимо динамически открывать до 6 портов на каждый (!) звонок: 2 порта для сигнального трафика в оба конца, 2 порта для голосового трафика и, опционально, 2 порта для контроля производительности (с помощью протокола RTCP). Если производитель свой продукт называет межсетевым экраном (firewall), но при этом строит его на базе обычного пакетного фильтра, входящего в состав операционной системы Linux или FreeBSD, то у такого защитного решения будут большие сложности с поддержкой IP-телефонии. Современный МСЭ таких проблем не имеет.  Когда вы хотите совершить звонок при помощи IP-телефона, то первым делом посылаете соответствующее сигнальное сообщение. Оно без особых проблем проходит через межсетевой экран и доходит до вызываемого абонента. Тот, в свою очередь, отправляет подтверждение, которое также проходит через МСЭ, «ожидающий» этот ответ. Но когда в дело вступает обмен голосовыми данными, ситуация коренным образом меняется. Исходящий «голос», вероятно, будет пропущен МСЭ, а вот входящий будет им отброшен, так как МСЭ ничего не знает об этом соединении и не «ждет» его. Ведь он не способен «посмотреть» выше транспортного уровня и «заглянуть» в глубь сигнальных пакетов, передаваемых на сеансовом уровне и хранящих сведения об используемых параметрах соединения (в том числе и портах). В результате соединение установлено, а слышать друг друга абоненты не могут – устаревший межсетевой экран (в отличие от современного) блокирует голосовой трафик.  Другая проблема связана с сетевой трансляцией адресов (Network Address Translation – NAT), которая обычно встроена в МСЭ и позволяет организовать соединение сети с широким диапазоном внутренних и зачастую не маршрутизируемых адресов с внешней сетью. Обычно NAT просматривает сетевой трафик на третьем сетевом уровне и заменяет указанные адреса источников внешне доступным адресом (например, адрес МСЭ). При этом выделяются порты, через которые и осуществляется взаимодействие с внешним миром. Для IP-телефонии в данном случае начинаются серьезные проблемы, потому что информация о параметрах соединения скрывается на два уровня выше – на сеансовом уровне. Это значит, что NAT «не сработает», и внешний абонент не сможет дозвониться до внутреннего пользователя – он его просто «не увидит». Традиционные средства сетевой безопасности тоже не учитывают такое понятие, как «приоритезация трафика», а ведь это один из ключевых показателей в инфраструктуре IP-телефонии. Неспособность обрабатывать голосовой трафик в реальном времени существенно снижает качество телефонных разговоров, если вообще их не блокирует.  Аналогичные возможности технология deep packet inspection реализует и для других сервисов и приложений. Параллельно с МСЭ с функцией Deep Packet Inspection на рынке стали появляться узкоспециализированные решения – межсетевые экраны приложений (application firewall), которые ориентировались на защиту отдельных приложений или сервисов на самом высоком уровне эталонной модели OSI – прикладном. Например, МСЭ для Web (Web firewall) обнаруживали и блокировали следующие виды несанкционированных действий:  -          манипуляция данными с помощью, например, атаки SQL Injection;  -          перехват сессий или кража учетных записей пользователей с помощью атак Cross-Site Scripting (XSS);  -          атаки «отказ в обслуживании» на web-серверы и т. п.  Анализируют Web firewall не весь трафик, а только HTTP, например, возможный вредоносный контент в запросах GET и POST. Некоторые производители могут контролировать и исходящий web-трафик, в частности, для отслеживания утечки конфиденциальной информации, персональных данных пользователей и т. д.  Однако узкая направленность прикладных межсетевых экранов приводила к тому, что они конкурировали за бюджеты с традиционными МСЭ, системами предотвращения атак и системами контроля содержимого. Несмотря на то, что эти защитные средства впервые появились 8 лет назад после выпуска компанией Sanctum своего продукта AppShield, ни один производитель этого рынка так и не преодолел планку 10-миллионного оборота. Постепенно этот сегмент стагнирует. Для сравнения приведем цифры по рынку средств управления патчами: за тот же период времени вырос из «ничего» до 200 млн долл. в год.  Web firewall? XML firewall? Нет! Application Assurance Platform!  Межсетевые экраны для Web решали и решают реальные задачи, но они постепенно вытесняются с рынка своими более «амбициозными коллегами». В частности, если, по данным Yankee Group, объем рынка МСЭ для Web в 2005 г. составил всего 40 млн долл. по всему миру (к слову сказать, таков объем продаж решений по информационной безопасности Cisco только в России), то рынок защиты XML (XML Security Gateway, или попросту XML firewall) оценивался в прошлом году на 25% выше – в 51 млн долл. Ежегодный рост этих сегментов также отличается – 10 и 25% соответственно в пользу МСЭ для XML. К 2009 г. доля Web firewall (да и других специализированных межсетевых экранов прикладного уровня) будет сведена практически к нулю, а доля XML firewall вплотную приблизится к заветной цифре в 100 млн долл. Однако обойдет всех новое направление на рынке средств защиты – конвергентные платформы для контроля приложений (application assurance platform, или AAP, согласно терминологии Yankee Group). Они будут включать в себя весь тот функционал, который требуется пользователям:  -          защищенная обработка и хранение конфиденциальной информации;  -          обнаружение и предотвращение мошенничества;  -          защита от атак типа «фишинг»;  -          анализ активности авторизованных пользователей;  -          балансировка нагрузки;  -          оптимизация работы с SSL-трафиком;  -          копирование трафика и проведение офлайн-анализа;  -          кеширование контента;  -          расширенная фильтрация трафика;  -          шифрование данных.   Экраны будущего  Технологии не стоят на месте, непрерывно совершенствуясь в соответствии с развитием бизнеса и изменяющимися потребностями пользователей. Попытаемся дать прогноз, какими будут межсетевые экраны ближайшего будущего.  Широкое распространение широкополосного доступа приводит не только к реализации лозунга «Интернет в каждый дом», но и к необходимости защиты каждого такого подключения. Однако ждать, что рядовые пользователи самостоятельно задумаются о своей защите, не стоит. Эту задачу должны взять на себя производители. Что они и делают (например, Linksys), встраивая межсетевые экраны в модемы или маршрутизаторы для широкополосного доступа.  Другая тенденция – «мобилизация» населения за счет увеличения объемов продаж мобильных телефонов, смартфонов, коммуникаторов и других устройств на базе «мобильника». Помимо связи, на эти устройства часто возлагается и задача хранения информации, зачастую конфиденциальной. С учетом возможности доступа к этому хранилищу извне задача его защиты становится более чем актуальной. Пока для таких мобильных и портативных устройств кроме антивирусов практически ничего не предлагается, но со временем ситуация изменится, и пользователю будет предоставлен широкий выбор межсетевых экранов для мобильных телефонов.  Если развить идею с application assurance platform и интегрировать в одном устройстве сразу несколько защитных решений, то мы получим так называемый Unified Threat Management Appliance – многофункциональное защитное устройство, которое позволяет сократить издержки и при этом обеспечить высокий уровень защиты за счет тесной интеграции таких защитных технологий, как межсетевой экран, система предотвращения атак, VPN, антивирус, антиспам, защита от шпионского ПО, контроль URL и т. п.  мнение специалиста Владимир Алферьев, менеджер по продукции ZyXEL Russia  Как показывают исследования, проведенные аналитической компанией TheInfoPro, специалистов по ИТ-безопасности не устраивают ни интегрированные платформы, оснащенные набором инструментов от одного производителя, ни набор аппаратных устройств от разных производителей, пусть даже и лидеров отрасли. Напротив, пользователи предпочитают иметь одно устройство, решающее весь комплекс задач по защите сети, и при этом объединяющее в себе решения производителей – лидеров по каждому из направлений сетевой безопасности.  Интересно, что современные интернет-технологии действительно позволяют реализовать весь этот противоречивый набор требований в одном устройстве. В качестве примера можно назвать устройства ZyWALL UTM, которые с октября прошлого года поставляются на российский рынок. В ZyWALL UTM объединены в единое целое технологии нескольких компаний: Blue Coat – контентная фильтрация; MailShell – защита от спама; «Лаборатория Касперского» – защита от вирусов.  В ZyWALL UTM реализована концепция онлайновых сервисов, когда заметная часть операций по обслуживанию устройства, обновлению сигнатур и баз данных осуществляется незаметно для пользователя – ему остается лишь задать начальные настройки и подписаться на услуги, которые он считает необходимыми для обеспечения надежной защиты своей сети от реально существующих сетевых угроз: от спама и фишинга до изощренных сетевых атак.  Еще один важный фактор – производительность. Как показывают исследования Infonetic Research, наиболее востребованными функциями защиты сети являются антивирус и обнаружение и предотвращение вторжений (IDP). Реализация этих функций «в лоб» требует мощных вычислительных ресурсов, поэтому для многих поставщиков достижение необходимой производительности стало серьезной преградой. Технология потоковой фильтрации, разработанная ZyXEL и реализованная в карте IDP и аппаратной защите от вирусов – ZyWALL Turbo Card, позволила реализовать требуемый уровень защиты и производительности и при этом сделать UTM-решение доступным по цене для предприятия малого и среднего бизнеса.  мнение специалиста Ашот Оганесян, технический директор ЗАО «Смарт Лайн Инк»  Действительно, число атак на компьютерные сети постоянно растет, поэтому при обеспечении информационной безопасности необходимо учитывать тот факт, что внутренние угрозы являются также весьма опасными. В большом количестве случаев внешние инциденты являются следствием внутренних. Например, когда вроде бы внешняя атака на корпоративную сеть проводится со знанием некоторой инсайдерской информации. Поэтому компании, установившие антивирусы и межсетевые экраны, должны понимать, что это далеко не панацея от всех угроз, и больше внимания следует обращать на средства контроля доступа к информации. Одним из широко известных решений является программный продукт DeviceLock компании «Смарт Лайн Инк», который контролирует доступ сотрудников к таким мобильным устройствам, как USB-флэшкарты, внешние и внутренние диски, и позволяет службам безопасности компаний осуществлять протоколирование всех файлов, копируемых сотрудниками на мобильные устройства хранения информации. 

15. Особенности файловой системы NTFS.

15 Особенности файловой системы NTFS

Автор: АЛЕКСАНДР ЛОЖЕЧКИН  Опубликовано в журнале "Компьютерра" №16 от 19 апреля 1999 года

В последнее время аппаратные средства стремительно дешевеют (в долларовом эквиваленте), и все большее число пользователей получает в распоряжение ресурсы, вполне достаточные для работы операционной системы Microsoft Windows NT (Pentium MMX 200 МГц, 32-64 Мбайт RAM). К мысли о переходе на NT приводит ненадежность и непредсказуемость Windows 95/98, а также их неспособность оптимально управлять ресурсами современных компьютеров.

При этом многие неискушенные пользователи не находят для себя ничего кардинально нового. И действительно, установив Internet Explorer 4 и не пользуясь многочисленными возможностями NT по усилению безопасности и защиты вычислительной системы, самое большое отличие от Windows 98, которое можно найти, это наличие двух папок "Автозагрузка" в пусковом меню (текущего пользователя и общей для всех пользователей) и отсутствие апплета Add/Remove Hardware в "Панели управления". А если еще и не форматировать диск под файловую систему NTFS, разницы не будет и подавно. Ниже я хочу рассказать как раз о некоторых преимуществах NTFS перед FAT, VFAT, FAT16 и FAT32. Общеизвестные отличия, такие как способность к самовосстановлению, отложенная запись, максимальный размер тома и файла на нем (до 16 экзабайт; 1 экзабайт = 1000000 гигабайт), возможность сжатия отдельных файлов и папок, установки разрешений и аудита, достаточно широко освещены в литературе и документации к Windows NT. Но существуют еще малоизвестные и малоиспользуемые возможности NTFS: жесткие ссылки (hardlinks) и множественные потоки данных (multiply data flows или forks). Далее пойдет речь именно о них. Множественные потоки данных. Этот термин знаком пользователям Macintosh. В этой системе файл может иметь два потока (forks): поток данных и поток ресурсов. В потоке данных хранятся собственно данные файла - этот поток и копируется как единственный при переносе файла с Macintosh на PC. Второй поток файла - поток ресурсов, содержащий данные операционной системы: меню, значки, шрифты, - словом, все то, что принято называть ресурсами. Когда Windows NT Server обслуживает клиентов Macintosh и предоставляет им дисковое пространство для хранения файлов, необходимо, чтобы файловая система сервера поддерживала формат файлов клиента. Это является одной из причин появления множественных потоков данных в NTFS. Каким образом это реализовано? Любая информация о файле, начиная с его имени, прав доступа и заканчивая собственно данными, хранящимися в файле, с точки зрения NTFS представляет собой атрибут, хранящийся в собственном потоке (stream). Разработчики NTFS решили не ограничиваться одним потоком для данных, безымянным, и добавили возможность создания нескольких, помимо основного, именованных потоков. Для создания множественных потоков можно применить функцию Win32 API, но есть пути и проще. Со времен Кернигана и Ричи, разработчиков языка C и операционной системы Unix, у многих операционных систем существует возможность обобщения операций ввода/вывода. С этой точки зрения любая операция ввода/вывода может рассматриваться как операция ввода из потока или вывода в поток независимо от того, что является источником данных (консоль, то есть клавиатура, файл или порт) и приемником (опять же консоль, в данном случае уже экран монитора, принтер или файл). Существует и возможность перенаправить ввод/вывод программы с экрана на принтер и вводить команды не с клавиатуры, а из файла. В наше время повсеместного использования графического пользовательского интерфейса эти возможности применяются очень редко, поэтому поясню сказанное примером. Команда echo операционных систем Microsoft используется для вывода информации на экран в текстовом режиме: C:\>echo Hello, World! Hello, World! C:\> Команда echo в качестве устройства вывода информации использует экран монитора. Вывод этой команды можно перенаправить с консоли в файл (для этого используется символ ">"): C:\>echo Hello, World! > file C:\> Как видите, команда echo в данном случае на экран ничего не вывела. Но в файле file можно обнаружить строку "Hello, World!". Аналогично вывод команды echo можно перенаправить и на принтер: C:\>echo Hello, World! > lpt1 C:\> На экране опять ничего, но на листе бумаги можно обнаружить все ту же строку "Hello, World!", если, конечно, принтер подсоединен к порту lpt1. Таким образом, вывод любой программы текстового режима можно перенаправить на любое устройство, поддерживающее потоковый ввод информации, или в файл, за исключением тех программ, которые в текстовом режиме используют для вывода информации непосредственную модификацию видеопамяти и другие нестандартные, с точки зрения классического C, возможности. Аналогично можно перенаправить и ввод программы. Команда more операционных систем Microsoft используется для буферизации вывода команд, выводящих информации больше, чем умещается на экран. Но эту команду можно использовать и для иллюстрации перенаправления ввода: C:\>more < file Hello, World! C:\> В файле file находилась строка "Hello, World!", которая была направлена на экран. Точно так же, с помощью перенаправления ввода/вывода, можно создавать и читать множественные потоки данных: C:\>echo string1 > file:fork1 Записью file:fork1 определяем в файле file поток с именем fork1 (поскольку он еще не существует, то создается новый с этим именем) и перенаправляем в него вывод команды echo. При этом размер файла при просмотре его свойств не изменяется, и стандартными средствами Windows NT, не зная имени потока, его существования определить нельзя. Но, зная его имя, можно с помощью команды more определить и его содержимое: C:\>more < file:fork1 string1 Таким образом, можно создавать и читать содержимое потоков данных файла. Количество потоков, создаваемых в одном файле, ограничено только объемом свободного пространства на жестком диске. Аналогично создаются потоки данных в каталогах, но для просмотра содержимого потока придется применить другое средство вывода потока на экран, так как команда more при этом выдает следующую ошибку: The instruction at "0x010013c2" referenced memory at "0x0061004d". The memory could not be "read". Если ничего подходящего найти не удалось, можно создать в любом компиляторе C++ такую программу: #include <iostream.h> void main () { char ch; while (cin.get(ch)) cout.put(ch); } Скомпоновать эту программу лучше как консольное Win32-приложение и использовать как средство для изучения потоков каталогов. Windows NT не предоставляет стандартных средств для получения информации о множественных потоках данных. Но что делать, если такая информация необходима? В этом случае можно воспользоваться программой streams Марка Руссиновича (Mark Russinovich), доступной, вместе с исходным кодом, на сайте www.sysinternals.com. В ней для получения информации о множественных потоках данных используются недокументированные функции Windows NT. Вот информация, полученная с помощью программы streams о файле file: C:\>streams file NTFS Streams Enumerator v1.0 Copyright (C) 1999 Mark Russinovich Systems Internals - www.sysinternals.com file: :fork1:$DATA 10 C:\> Здесь можно видеть как название потока данных, так и его размер в байтах (дополнительные три символа - это пробел перед символом ">", возврат каретки и перевод строки, добавляемые командой echo). К сожалению, streams не позволяет определить множественные потоки данных в каталогах. Каковы пути применения множественных потоков данных? Помимо применения, найденного для них фирмой Apple, можно указать на самое простое средство для скрытия информации, например, для запоминания даты установки программы shareware. На заре технологии OLE компания Microsoft предполагала использовать потоки данных для хранения информации о внедренных объектах, но, видимо, обеспечить потоки данных на FAT оказалось сложнее, чем создать длинные имена файлов, и от этой идеи пришлось отказаться. Создание "файла ресурсов" для скрипта с хранением в нем всех надписей, выводимых на разных языках, также может быть интересной областью применения потоков. Помимо приведенных, существует множество других интересных применений для множественных потоков данных. Жесткие ссылки. Пользователям различных клонов Unix хорошо знакомо это понятие. В отличие от файловой системы FAT, в которой принято, что у каждого файла может быть только одно имя, Unix от такого ограничения освобождена: каждый файл может иметь несколько имен, и его данные не могут быть удалены, пока счетчик имен файла не равен нулю. В Unix существуют также символьные ссылки - аналог ярлыков (shortcut) в Windows, но следящие за перемещением объекта, на который они ссылаются. Windows NT ограниченно соответствует стандарту POSIX (Portable Operating System Interface for Computing Environments). Один из примеров ограниченности - поддержка жестких ссылок и отсутствие поддержки символьных. Видимо, было решено, что ярлыки являются достойным аналогом символьных ссылок. В NTFS жесткие ссылки организованы аналогично множественным потокам данных: если у файла есть несколько потоков с данными, почему не может быть нескольких потоков с именами? Несколько имен файла могут находиться в разных каталогах, но только в пределах одного раздела. Для изготовления жесткой ссылки необходима программа для подсистемы POSIX Windows NT. Такая программа вместе с исходными текстами находится на компакт-диске "Ресурсы Windows NT". По аналогии с Unix эта программа называется ln. Синтаксис этой команды: C:\>Ln file hardlink1 С помощью этой команды мы создаем для файла file второе имя, или жесткую ссылку hardlink1. При изменении содержимого файла file изменяется и содержимое hardlink1, то есть по сути это один и тот же файл, но с двумя именами. Аналогично можно менять и другие атрибуты файла. Количество имен у файла не ограничено, но при копировании имени файла ссылка разрывается, и создается еще один файл. Существует возможность создания ссылки в другом каталоге: C:\>Ln file ../temp/hardlink2 В этом случае необходимо указывать не абсолютное, а относительное имя каталога. Для жестких ссылок можно найти не меньше применений, чем для множественных потоков данных. Например - создавать жесткие ссылки для библиотек dll, чтобы обезопасить свою программу от случайного удаления необходимого файла. Другие возможные применения жестких ссылок лучше всего искать в литературе, относящейся к Unix. И, конечно же, применение жестких ссылок можно комбинировать с описанными выше множественными потоками данных.

16. Второе поколение сетевых экранов.

17. Процесс загрузки ОС.