ExFAT - файловая система для Mac OS X и Linux. Файловые системы Mac OS

Файловые системы Mac OS X

Виртуальная файловая система

Права доступа к съемным носителям

URL-монтирование AppleShare- и Web-серверов

Длинные имена файлов

Дисковые файловые системы HFS, HFS+, UFS

" поддержка CD /DVD-дисков UDF, ISO 9660

Сетевые файловые протоколы AFP, NFS

Mac OS X работает с различными файловыми системами. Для этого используются расширения системы BSD и механизм, называемый виртуальной файловой системой (Virtual File System, VFS). Поддержка различных файловых систем включает в себя некоторые новые функции, которых не было в предыдущих версиях Mac OS:

Права доступа к съемным носителям, основанные на уникальных идентификационных номерах (ID), регистрируемых в системе для каждого подключенного устройства со съемными носителями, включая USB-и Firewire-устройства).

Основанное на URL монтирование томов, что позволяет монтировать тома на AppleShare- и Web-серверах.

Длинные имена файлов (до 255 символов, или 755 байт на основе UTF-8).

Из-за наличия трех различных сред, в которых запускаются и работают программы (см. «Поддержка прикладных программ»), и множества типов носителей информации Mac OS X должна поддерживать несколько форматов носителей данных и сетевых файловых протоколов.

Форматы носителей, с которыми работает Mac OS X, представлены в таблице 20 «Файловые системы».

Множество форматов файловых систем на магнитных дисках создают некоторые сложности при обмене документами между томами. Например, классическая файловая система HFS поддерживает только так называемую MacRoman-систему кодировки символов в именах файлов и папок. Файловая система HFS+ использует канонический набор символов Unicode 2.1 в формате UTF-16, то есть в виде последовательности 16-разрядных кодов. Файловая система UFS также поддерживает полный набор символов Unicode 2.1, но только в формате UTF-8. Поэтому, чтобы уменьшить количество проблем, настоятельно рекомендуется не использовать Таблица 20. Файловые системы

Таблица 21 . Сетевые файловые протоколы

файловую систему HFS при работе с Mac OS X, несмотря на то, что формально это не запрещено.

Так как Mac OS X рассчитана на работу в сложных гетерогенных средах, она поддерживает несколько сетевых файловых протоколов (см. табл. 21 «Сетевые файловые протоколы).

Mac OS X поддерживает механизм дисковых квот. Это означает, что для каждого локального или удаленного пользователя администратор системы может устанавливать лимит дискового пространства. Квотирование распространяется практически на все перезаписываемые устройства с файловой структурой.

Файловые системы HFS, HFS+: особенности структуры файлов

Ветвь ресурсов (resource fork), ветвь данных (data fork)

Упаковка/распаковка Mac-файлов; BinHex-формат

Ресурсные файлы

Атрибуты Finder"a

Тип файла (type), создатель файла (creator)

Файлы файловых систем HFS и HFS+ состоят из двух логических частей - двух «внутренних файлов», называемых ветвями (forks).

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

Ветвь данных (data fork) предназначена для хранения динамически создаваемых данных. Программы могут записывать в нее любую информацию.

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

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

Чтобы такого не происходило, приходится принимать специальные меры: сначала создается «обычный» файл, в котором обе ветви Mac-файла упаковываются в специальном формате BinBex. Такой файл передается по компьютерным сетям без потерь. При получении файла-контейнера он распаковывается - из «обычного» файла получается файл формата HFS или HFS+ с двумя ветвями. Это хлопотно и неудобно для большинства пользователей. Поэтому фирма Apple в настоящее время рекомендует разработчикам программ не использовать ветвь ресурсов файлов HFS и HFS+, а создавать отдельные ресурсные файлы, в которых все необходимые ресурсы расположены исключительно в ветви данных. Так, например, новый тип шрифтовых файлов Mac OS X, имеющих расширение.dfont,- это, по сути, обычные шрифтовые файлы, все ресурсы которых перенесены в ветвь данных. Кроме того, программы для Max OS X должны создаваться по новой идеологии, ко торая учитывает эти изменения в организации хранения ресурсов [см. «Пакеты (bundles)»].

Помимо ветви ресурсов и ветви данных каждый файл содержит дополнительные признаки, называемые атрибутами Finder"a. Атрибуты распознаются и обрабатываются Finder"oм при отображении информации о данном файле или попытке его открыть (распечатать).

В Mac OS X сокращено количество атрибутов, обрабатываемых Finder"oM. Теперь этот список включает в себя:

Бит пакета (bundle bit),

Бит невидимости (invisible bit),

Коды типа файла и программы-создателя файла (type & creator),

Оригинальную иконку файла (custom icon).

Атрибуты, которые больше не поддерживаются Findre"OM:

Место расположения иконки на Столе,

Форма отображения информации о файле (view),

Этикетка (label).

Пожалуй, наиболее важными и наиболее специфическими являются атрибуты создатель файла (creator) и тип файла (type). Они помогают Finder"y принять правильное решение при открытии (печати) файлов.

Когда мы пытаемся открыть файл-программу, для Finder"a все понятно: надо просто запустить эту программу, а дальше она сама знает, что ей делать.

При открытии файла-документа приходится решать более сложную задачу. Сначала Finder проверяет код программы-создателя этого документа. Если на данном компьютере имеется нужная программа, она запускается и открывает указанный документ. Логика такого поведения очевидна: «автор» документа лучше всех знает, как с ним работать.

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

Если не находится ни одной программы, о которой системе известно, что она умеет работать с документами данного типа,- вызывается диалоговое окно, в котором вам предлагается самостоятельно выбрать подходящую. Ес ли указанная вами программа успешно открыла документ, то система запоминает это и в следующий раз сразу запускает ее.

Хранение информации о типе файла внутри самого файла имеет важное достоинство: никакое переименование файла не может изменить его тип, то есть суть файла не зависит от его имени.

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

В процессе форматирования компьютер предлагает выбрать файловую систему (ФС). Так называют способ организации данных на флешке. Пользователю macOS доступен выбор из следующих систем: MS-DOS (FAT), ExFAT или OS X Extended.

Очень важно отформатировать накопитель в той ФС, которая лучше всего подходит для вашей техники. Давайте разберёмся, какая файловая система флеш-драйва будет оптимальной для Mac и почему.

Виды файловых систем и их особенности

MS-DOS (FAT) - так macOS называет ФС, известную пользователям Windows как FAT/FAT32. Она совместима с любыми компьютерами, а также поддерживается консолями и бытовой техникой вроде видеокамер или даже стареньких медиапроигрывателей.

При всей своей универсальности MS-DOS (FAT) имеет важный недостаток: на отформатированную в этой файловой системе флешку нельзя записывать файлы, размер которых превышает 4 ГБ.

ExFAT - более новая ФС, которая поддерживается в среде macOS, начиная с версии X 10.6.5, а в Windows – с XP SP2. Очевидно, что недостатком этого формата можно считать отсутствие совместимости с более ранними вариантами операционных систем. Кроме того, не все USB-устройства поддерживают ExFAT. Ну, а плюс в том, что он способен работать с файлами объёмом более 4 ГБ.

Mac OS Extended (Journaled) обеспечивает максимальную совместимость флеш-драйва с macOS и является файловой системой по умолчанию для жёстких дисков на компьютерах Mac. Никаких ограничений на размер записываемого файла при использовании Mac OS Extended (Journaled) нет. В то же время эта ФС не поддерживается Windows и многими USB-устройствами.

Вы также можете увидеть в списке доступных ФС Mac OS Extended (Case-sensitive, Journaled) . Она отличается от предыдущей только чувствительностью к регистру. Например, файлы hello.txt и Hello.txt в такой ФС будут считаться разными. Если вам этого не нужно, выбирайте обычную Mac OS Extended (Journaled).

NTFS - ещё одна ФС, с которой вы можете столкнуться. Отформатированные в ней накопители не имеют ограничений по объёму файлов и совместимы с Windows. Но в macOS записанные на такую флешку файлы можно лишь просматривать без возможности записи. Кроме того, некоторые USB-устройства вообще не поддерживают NTFS.

Какую файловую систему выбрать

Как видите, выбор файловой системы накопителя зависит от того, с какими устройствами вы будете его использовать. Если только с Mac и другой техникой Apple, выбирайте Mac OS Extended (Journaled).

Для Mac и Windows-ПК отлично подойдёт ExFAT.

Если хотите добиться совместимости флешки с максимальным количеством USB-устройств и не планируете записывать на неё файлы больше 4 ГБ, выбирайте MS-DOS (FAT).

Как поменять файловую систему

Чтобы изменить ФС накопителя, его с помощью «Дисковой утилиты». Не забывайте, эта процедура уничтожает все данные.

Но сначала проверьте текущую файловую систему флешки. Для этого достаточно запустить «Дисковую утилиту» и выделить накопитель на левой панели. После этого на экране появится детальная информация о флешке, в том числе тип её ФС, который можно увидеть рядом с названием накопителя.

Если текущая файловая система вас не устраивает, кликните на верхней панели по кнопке «Стереть». В появившемся окне выберите новую ФС и снова нажмите «Стереть». Через несколько секунд утилита изменит файловую систему флешки.

Всем привет. Недавно я задался вопросом как организовать обмен файлами между операционными системами. Предположим, я хочу установить сразу три основные ос на своём ноутбуке: линукс, виндовз и хакинтош. Каждая ос предназначается для своих задач: Линукс - для работы и программирования, винда - для игр и хак - просто для разных экспериментов.

Поскольку я создаю обучающие видео ролики о линуксе, мне удобнее работать именно на нём. Но монтировать хочется попробовать в «финальном вырезе». Уж очень мне приглянулась идея магнитной ленты времени.

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

Как такая задача решалась мной раньше? Раньше я использовал только винду с линуксом, поэтому задачи обмена с apple os не возникало. Конечно, хотелось использовать открытую и родную фс для линукса - ext4. Но на винде её смонтировать непросто. Нужно устанавливать бесплатный (но проприетарный) Paragon ExtFS for Windows. И ладно, если бы это работало, но к сожалению данное ПО повреждает вам раздел с линуксом. Напоролся пару раз, и всякое желание пользоваться этим по пропало.

А вот виндовая фс под линуксом читается и пишется без проблем. Нужно всего лишь установить ntfs-3g драйвер. Он работает в юзерспейсе. Файловая система проприетарная, но решение работает.

Теперь же я хочу использовать ещё и хакинтош, и хочется разобраться какие ещё есть варианты для решения этой задачи, кроме ntfs.

На самом деле вариантов немного. Давайте разберёмся, какие есть файловые системы, и какие из них являются более или менее универсальными.

Fat32 - всем известная древняя фс, является самой универсальной в плане переносимости, но и самой убогой в плане ограничений. Была разработана давно, не поддерживает файлы размером более 4 Гб. Проприетарная. Для моих задач не подходит.

Ntfs - родная фс для винды, проприетарщина. Линукс, как я уже писал выше, её поддерживает с помощью стороннего драйвера (ntfs-3g). Мак нативно её не понимает, хотя можно доустановить соответствующее по. Есть несколько вариантов, как платных, так и бесплатных. Ни один из них мне не нравится. ntfs-3g работает в userspace (с медленной скоростью), а платные решения - платные.

Hfs+ - одна из худших фс, когда либо созданных. Родная для мак ос, но нисколько не универсальная. Можно примонтировать на линуксе, а для винды опять же есть платные решения - в пролёте.

Ext4 - одна из правильных фс, родная для линукс. Но в плане монтирования в неродных ос - опять проблемы. За платные решения для хакинтоша и для винды опять просят денег. Есть и бесплатные решения, к примеру ext2fsd, но этот драйвер не умеет писать в ext4. В пролёте.

Udf - одна из правильных фс, поддерживается нативно всеми ос. Эта фс была бы лучшим вариантом, если бы не компания apple. Изначально udf создавалась для оптических носителей, но она может быть спокойно использована на обычном жёстком магнитном диске. НО! Из-за того, что яблочники не реализовали поддержку этой фс с раздела, вся задумка отменяется. Даже последняя мак ос Х поддерживает данную фс только если всё блочное устройство не имеет таблицы разделов. На гитхабе есть скрипт format-udf , который может подготовить носитель специальным образом: в начальном блоке данных прописывается mbr, говорящий что раздел начинается прямо там же где и сам mbr. Т.е. накопитель как бы одновременно и с таблицей разделов (то что понимает винда), и вроде как и без таблицы разделов. Этот способ предполагает что носитель будет внешний, а мне нужно сделать exchange раздел именно на внутреннем накопителе. Так что данный вариант тоже в пролёте.

exFat - проприетарщина, но нативно работает как в винде, так и в маке. Это очень хорошо. А что в линуксе?

Вкратце история:

Эта фс использовалась для sd карт на андроидах, а там у нас линукс ядро. Производители реализовали драйвер exfat для linux ядра и никому его не показывали. Но некто в интернете слил на гитхаб их код. Было понятно, что это воровство, и в таком виде код в ядро попасть не мог. Однако, в этом коде сообщество нашло куски gpl кода, что разумеется, требовало раскрытия всех исходников, т.е. это было уже воровство у сообщества со стороны компании samsung. Через некоторое время самсунг выпустили этот код под gpl лицензией.


Спрашивается, а почему тогда данный драйвер не поддерживается из коробки? Потому что его нет в ядре. Мердж этого кода (пусть и gpl-ного) в mainline - это по сути троян от мелких (из-за патентов). Торвальдс это понимает, и, понятное дело, ядро не отравит.

В линуксе монтировать exfat можно либо с помощью exfat-fuse драйвера, либо с помощью exfat-nofuse. Конечно, лучше nofuse, так как он будет работать быстрее. Но его придётся собирать каждый раз при обновлении ядра. Благо, для автоматизации этой задачи есть механизм dkms.

Подведём итог

Я останавливаюсь на exfat. Да, проприетарщина, но ничего не поделаешь. Зато всё нативно работает, и “танцы с бубном” отсутствуют: во всех трех операционных системах есть нативная поддержка и возможность поставить эту фс именно на раздел. Ограничения в 4 Гб нет. И в целом, это решение достаточно простое.

Надеюсь, вы узнали что-то новое для себя и выберите подходящий вариант исходя из ваших нужд.

В возникновении мифа о примитивности и никчемности Mac’ а виноваты его создатели. Они слишком хорошо сделали свою работу. Система Mac’а была сложней и интереснее всех популярных систем того времени, внутри. Внешне все было очень просто, и просто работало.

А зачем пользователю знание подробностей анатомии и физиологии его персонального помощника?

Самая худшая разновидность “экспертов” – нахватавшиеся верхушек дилетанты. Те, кто и в самом деле владел темой, Mac оценили по достоинству. Их не обманула скупая простота интерфейса, они нашли его очень продуманным, логичным и удобным. “Сегодня я увидел, какими будут компьютеры лет через пять”, – говорили они.

А вот “эксперты” пришли в недоумение: кому нужен этот пластиковый “говорящий” ящик, если в нем совершенно невозможно разобраться? Нет ни командной строки, ни текстовых файлов со скриптами или с настройками конфигурации. Ничего нет, вообще! Ну никак не заглянуть ему “в душу”!

Вскрыть корпус? На нем табличка: “Не вскрывать, внутри нет ничего интересного”. Кто-то все-таки вскрыл и, действительно, ничего интересного не нашел. Платы, микросхемы…

Интересно, что они надеялись там увидеть? Крошечного инопланетянина, прикованного к микроскопическому пульту управления, с миской сушеных инопланетных червяков?

Finder и файловая система

Оболочка операционной системы Mac’ов с её первого дня и до сих пор называется Finder. “Тот, кто что-то находит”. На границе 80-х и 90-х, когда объёмы дисковых хранилищ стали большими, возник анекдот: Finder that finds nothing (Finder, который ничего не находит), но в 1984 году, на дискете ёмкостью в 400 K спрятать что-то было нелегко.

Это классическое Mac’овское приложение, написанное Брюсом Хорном и Стивом Капсом. Брюс – гений и перфекционист, “псих-одиночка”. Работать с ним над одной задачей не мог никто и никогда. Но осенью 1983-го, когда до последнего и окончательного срока завершения проекта оставалось всего ничего, Finder “застрял”.

Стив Капс смог найти общий язык с Брюсом. Проблемы были абсолютно объективные, но вдвоем они справились. В декабре 1983 года Finder был готов к выходу в свет. В тот день разработчики Mac’а устроили “день Стива Капса” – все пришли одетыми, как одевался он.

По мнению журналистов, главной функцией Finder было управление файловой системой Mac’а. Добавим в это определение только одно слово: “Главной видимой функцией…”. Это реализация метафоры “рабочего стола”, с документами и инструментами для работы с ними.

Файловая система первого Mac’a называлась MFS (Macintosh File System). В ней не было иерархии директорий, она была “плоской”, как плохая шутка, но для дискеты ёмкостью в 400 килобайт, значительную часть которой съедала система, это было необходимо.

Директории (по Mac’овски – папки) в MFS на самом деле были иллюзией. Их было видно только в Finder. Ссылки на все объекты файловой системы хранились в одном невидимом файле небольшого размера.

Иерархическая файловая система (HFS) была написана намного раньше, но на время её убрали в архив. Вплоть до System 3.0 на Mac’ах использовалась только MFS.

На системной дискете изначально было две папки – System Folder и Empty Folder. В Empty Folder пользователь мог “убрать” свои документы и программы, как в ящик письменного стола. Взяв нужный файл и перетащив его в открытую или закрытую папку. Empty Folder можно было переименовать. И в момент завершения переименования случалось чудо: на рабочем столе немедленно появлялась новая пустая папка с названием Empty Folder.

Файловая система самого первого Mac’а называлась MFS (Macintosh File System), она была предназначена и оптимизирована под односторонние 3,5-дюймовые дискеты с ёмкостью в 400 килобайт, и над ней смеялись. Она была “плоская”. В ней были только “диск” (та самая дискета) и файлы. Иерархии директорий (папок, если по Mac’овски) не было.

При удалении Empty Folder (для этого её надо было перетащить в “урну” (Trash) и выбрать в меню Special команду “Empty Trash”. При опустошении урны уничтожалось всё, что было в ней, – пользователей приучали к мысли, что это невосстановимо. На самом деле, если с момента уничтожения этих файлов не создавалось новых, все еще можно было поправить, с помощью специального инструмента – правда, появился он, как мне кажется, в 1985-м.

Теоретически восстановить файл можно было с помощью 16-ричного редактора, вручную изменив содержимое невидимого списка файлов и папок, но это было за пределами добра и зла: требовалось найти потерянный файл, правильно привести его положение на диске в обозначение, понятное “невидимому файлу”, исправить информацию самого “невидимого файла” и нигде не ошибиться – иначе системная дискета переставала загружать систему. Отправленный в урну по ошибке (или ради эксперимента) файл можно было вернуть на место с помощью команды Put Back в меню File. Если “мусор еще не выносили”.

Имена файлов предназначались для пользователей, файловая система использовала для их идентификации уникальные идентификаторы файлов (числа). В именах файлов и папок можно было использовать абсолютно любые символы, кроме двоеточия.

MFS мог работать с именами файлов длиной до 255 символов, но Finder ограничивал полет фантазии пользователя жалкими 63. В одной из версий (в 3.0, кажется) длину имени файла еще раз ограничили, на этот раз 31 символом. Это ограничение дожило до 1998 года.

То есть, если “системный шрифт для вывода имен файлов в Finder” знал кириллицу, папка могла бы называться “Я. Избранное. За 1984..1987 годы”. А документы в ней, например, “Сказка про беглого бычка”.

Содержимое активного (выбранного) окна при желании можно было распечатать, один в один. Если был принтер. Или отправить по факсу – если был модем и программа отправки факсов.

MFS могла работать с дисковым пространством до 20 Мегабайт, или с 1400 файлами, во времена, когда единственным доступным хранилищем информации были односторонние дискеты ёмкостью в 400 К, эти ограничения были теоретическими.

Объекты файловой системы

Я в предыдущем разделе называл видимые пользователем объекты файловой системы словом “файл”. Это, с точки зрения дизайнеров (в хорошем смысле этого слова) Mac’а, грех. В системе Mac’а файлов не было, были только приложения, документы приложений и документы системы.

Метафора рабочего стола – это такая ролевая игра.

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

Работу с приложением можно было начать двойным кликом по его иконке – если на диске не было документов нужного типа или если так было удобнее. Или если у приложения не было никаких документов в принципе (игра, 16-ричный редактор диска и тому подобное).

В ролевой игре не участвовали только системные документы, за небольшим исключением двойной клик по их иконкам не приводил ни к каким действиям. Их не стали прятать, и это хорошо. Вам приходилось устанавливать драйвер, например, принтера, в PC DOS? А вот на Mac’е весь процесс состоял в перетаскивании документа системы, например “Image Writer LQ”, в системную папку. Убрать принтер из числа работающих, не удаляя его ценный системный документ (драйвер), можно было, убрав его иконку из System Folder.

Откуда документы и приложения знали, какими иконками изображаться их на экране и как кого открывать? Ведь никаких расширений файлов в MFS не было. Если вы не знали о том, как это делается, но сами задались этим вопросом, я вами горжусь.

Текст хранится в компьютерах в виде последовательности чисел. В эпоху классических ОС каждый символ обозначался байтом, числом длиной в 8 бит. Заглавные и строчные буквы, знаки препинания, цифра, пробел и т. п. А еще – “непечатные” символы вроде “возврата строки”, “звукового сигнала”, “перехода на следующую строку” и им подобные. В наши дни используются значительно более разорительные кодировки, но я вам про них не расскажу.

Инженеры команды Macintosh придумали тип данных, OSType, значение которого было числом, но на экране отображалось как последовательность из 4 букв. OSType применялся в Mac’овской системе для мнемонического обозначения самых разных сущностей.

Тип файла отображался двумя атрибутами типа OSType, первый из которых обозначал его формат (Type Code), а второй (Creator Code), в случае, если файл – приложение, хранил мнемонику APPL, если документ – тип создавшего этот документ приложения. Это не все возможные варианты “создателя”, остальные (системные документы, драйверы и т. п.) нас не интересуют.

Каким бы образом видимый пользователю файл ни оказывался в хранилище MFS или HFS, система тут же заносила сведения о его атрибутах и иконке в специальный файл, не видимый пользователями. Двойной клик по документу включал алгоритм поиска создателя этого документа – приложение с типом файла, равным создателю файла. Если в пределах диска такого не было, искалось приложение, умеющее работать с этим типом документов.

Конфликты? Случались. Но гораздо реже, чем в PC DOS. На Mac’е тип файла обозначался восемью символами вместо трех в PC DOS. Заглавные и строчные буквы в Mac’овском обозначении типов файлов различались, и никто не запрещал использовать в качестве уникальных значений любые символы.

Система первых Mac’ов не поддерживала многозадачность. В любой момент на компьютере работала одна программа, или прикладная, или системная – то есть Finder.

Между тем, в процессе разработки Mac’а быстро обнаружилась потребность в утилитах, которые всегда под рукой. Калькулятор, будильник, карта текущей раскладки клавиатуры и много чего еще.

Решение было найдено. Назвали его Desktop Accessories, или DA’s. Аксессуары рабочего стола. По своей природе это были драйверы специального типа. Жили они в оперативной памяти, выделенной работающему приложению. Можно было запустить любое их число, но при этом запросто можно было нанести ущерб приютившему их приложению.

Доступ к DA’s осуществлялся из меню “Яблоко”, содержание которого не зависело от запущенного приложения. DA писали не только в Apple, но и сторонние разработчики.

Продолжение следует.

  • Почему невозможно записать файлы на внешний жесткий диск?
  • Почему большой файл не копируется на флешку или диск?
  • Как стереть все данные с флешки на Mac OS?

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

ExFAT – расширенная FAT . ExFAT это производная от MS-DOS (FAT), в которой устранили основные недостатки. Но как и прежде, она предназначенная главным образом для флеш-накопителей, поскольку операционные системы не могут бысть установленны на диск с такой файловой системой.

Размер раздела с файловой системой ExFAT практически неограничен, а размер файла теоретически ограничен до 16 эксабайт (16 миллиардов ГБ). Из недостатков – не все операционные системы поддерживают ее. С ExFAT работают компьютеры под управлением Windows XP SP2 или новее и Mac OS X 10.6.5 или новее.

NTFS – файловая система которая используется в операционных системах Windows которая как exFAT пришла на смену системе FAT. Актуальная версия – 3.1 которая используется в операционных системах начиная с Windows XP и по сегодняшний день. Максимальный размер диска – 16 эксабайт, а размер одного файла не может превышать 16 эксабайт. т.е. фактического ограничения на размер файла нет.

С форматом NTFS Mac OS X по умолчанию работает в режиме чтения. Но после выхода Mac OS X 10.6 была найдена возможность активации функции записи с помощью стандартного драйвера, который предустановлен в операционной системе. Об этом мы напишем в отдельной статье.

А пока, если вам нужно добавить функцию полноценной работы Mac OS X с NTFS, рекомендуем воспользоваться одной из программ:

  • MacFUSE 2.0
  • Paragon NTFS для Mac OS X
  • NTFS-3G для Mac OS X

Схема разделов

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

Обращать внимание, в большинстве случаев, вам надо на файловую систему, а не на схему разделов. Схема разделов используется во время загрузки с жесткого диска или носителя.

Схема разделов GUID (Globally Unique Identifier) – Схема разделов, которую используют все компьютеры Mac на процессорах Intel. И также единственная схема разделов, с которой Intel-Мак может загружаться.

GUID опирается на расширенные возможности EFI для осуществления загрузки операцинной системы Mac OS или любой другой, которая усановленна на вашем компьютере. Но в разделе GUID есть и данные схемы разделов MBR (описана ниже), которые присутствуют в самом начале диска как для защиты, так и в целях совместимости.

Поэтому, если вы хотите сделать загрузочный диск и у вас Mac на процессоре Intel, значит жесткий диск или любой другой носитель у вас должен быть в схеме разделов GUID с форматом Mac OS Extended (Journaled)

Схема разделов APM (Apple Partition Map) – Эта схема разделов использовалась по умолчанию в компьютерах Мак на основе архитектуры PowerPC с процессором PowerPC G3, G4, G5, от знаменитой компании IBM (не Intel). Это также единственная схема разделов, с которой PowerPC-Мак может загружаться.

Apple отказалась от этой схемы разделов c 2006 года поскольку из-за 32-битных счётчиков максимальный размер диска при размере блока 512 байт может быть лишь 2 TB.

Поэтому, если вы хотите сделать загрузочный диск, и у вас Mac на процессоре IBM значит жесткий диск или любой другой носитель у вас должен быть в схеме разделов APM с форматом Mac OS Extended (Journaled). Но такие копьютеры не поддерживают загрузку с USB томов, а только с FireWire. Так что для этих целей флешка не подойдет, а только внешний жесткий диск с FireWire накопителем.

MBR (Master Boot Record) – Схема разделов, которая по умолчанию используется в большинстве PC компьютеров(80%), включая Windows- совместимые РС. Эту схему разделов вы найдете на большинстве форматированных перед продажей накопителей и флешек. Ни один из Мак компьютеров не поддерживает загрузку с этой схемы разделов, но могут с ней работать.

Эта схема разделов с техникой Apple, в качестве загрузочной не работает, но она нам может очень пригодиться при форматировании обычной флешки. Windows компьютеры не понимают схему разделов GUID, поэтому если вам нужна обычная флешка, нужно проверить, что у нее схема разделов MBR, а формат FAT или exFAT.

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



Просмотров