Объект в файловой системе упрощающий организацию файлов: Каталог, файловая система. Каталог — каталог, директория, справочник, папка — ПКРЕГИОН компьютерный магазин в Екатеринбурге недорогой техники каталог и цены с доставкой

Содержание

Каталоги и приемы их организации

Катало́г — объект в файловой системе, упрощающий организацию файлов. Типичная файловая система содержит большое количество файлов, и каталоги помогают упорядочить её путём их группировки.

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

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

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

Основные системные вызовы для работы с каталогами:

· Create — создать каталог

· Delete — удалить каталог

· OpenDir — закрыть каталог

· CloseDir — закрыть каталог

· ReadDir — прочитать следующий элемент открытого каталога

· Rename — переименование каталога

· Link — создание жесткой ссылки, позволяет файлу присутствовать сразу в нескольких каталогах.

· Unlink — удаление ссылки из каталога

Методики размещения файлов.

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

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

Проблема в том, что для дисков большого объема число блоков может быть слишком большим. Допустим, в некоторой файловой системе размер блока равен 512 байт, а для хранения номеров блоков файла используются 16-разрядные числа. В этом случае размер области данных диска не сможет превысить 512 * 216= 32 Мб. Конечно, можно перейти к использованию 32-разрядных номеров блоков, но тогда суммарный размер информации о размещении всех файлов на диске становится чересчур большим. Обычный выход из этого затруднения заключается в том, что минимальной единицей размещения файлов считают кластер (называемый в некоторых системах блоком или логическим блоком), который принимается равным 2kсекторов, т.е., например, 1, 2, 4, 8, 16, 32 сектора, редко больше. Каждому файлу отводится целое число кластеров, и в информации о размещении файла хранятся номера кластеров, а не секторов. Увеличение размера кластеров позволяет сократить количество данных о размещении файлов «и в длину и в ширину»: во-первых, для каждого файла нужно хранить информацию о меньшем числе кластеров, а во-вторых, уменьшается число двоичных разрядов, используемых для задания номера кластера (либо при той же разрядности можно использовать больший диск). Так, при кластере размером 32 сектора и 16-разрядных номерах можно адресовать до 1 Гб дисковой памяти.

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

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

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

Реализация файловых систем.

Фа́йловая систе́ма — порядок, определяющий способ организации, хранения и именования данных на носителях информации в компьютерах, а также в другом электронном Файловая система определяет формат содержимого и физического хранения информации, которую принято группировать в виде файлов. Конкретная файловая система определяет размер имени файла (папки), максимальный возможный размер файла и раздела, набор атрибутов файла. Некоторые файловые системы предоставляют сервисные возможности, например, разграничение доступа или шифрование файлов.

Файловая система связывает носитель информации с одной стороны и API для доступа к файлам — с другой. Когда прикладная программа обращается к файлу, она не имеет никакого представления о том, каким образом расположена информация в конкретном файле, так же, как и на каком физическом типе носителя (CD, жёстком диске, магнитной ленте, блоке флеш-памяти или другом) он записан. Всё, что знает программа — это имя файла, его размер и атрибуты. Эти данные она получает от драйвера файловой системы. Именно файловая система устанавливает, где и как будет записан файл на физическом носителе (например, жёстком диске).

С точки зрения операционной системы (ОС), весь диск представляет собой набор кластеров (как правило, размером 512 байт и больше)[1]. Драйверы файловой системы организуют кластеры в файлы и каталоги (реально являющиеся файлами, содержащими список файлов в этом каталоге). Эти же драйверы отслеживают, какие из кластеров в настоящее время используются, какие свободны, какие помечены как неисправные.

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

файловая система должна организовать эффективную работу с данными, хранящимися во внешней памяти, и предоставить пользователю возможности для запоминания и выборки этих данных.
Для организации хранения информации на диске пользователь вначале обычно выполняет его форматирование, выделяя на нем место для структур данных, которые описывают состояние файловой системы в целом. Затем пользователь создает нужную ему структуру каталогов (или директорий), которые, по существу, являются списками вложенных каталогов и собственно файлов. И наконец, он заполняет дисковое пространство файлами, приписывая их тому или иному каталогу. Таким образом, ОС должна предоставить в распоряжение пользователя совокупность системных вызовов, которые обеспечивают его необходимыми сервисами.
Кроме того, файловые службы могут решать проблемы проверки и сохранения целостности файловой системы, проблемы повышения производительности и ряд других.
Общая структура файловой системы
Система хранения данных на дисках может быть структурирована следующим образом (см.).
Нижний уровень — оборудование. Это в первую очередь магнитные диски с подвижными головками — основные устройства внешней памяти, представляющие собой пакеты магнитных пластин (поверхностей), между которыми на одном рычаге двигается пакет магнитных головок. Шаг движения пакета головок является дискретным, и каждому положению пакета головок логически соответствует цилиндр магнитного диска. Цилиндры делятся на дорожки (треки), а каждая дорожка размечается на одно и то же количество блоков (секторов) таким образом, что в каждый блок можно записать по максимуму одно и то же число байтов. Следовательно, для обмена с магнитным диском на уровне аппаратуры нужно указать номер цилиндра, номер поверхности, номер блока на соответствующей дорожке и число байтов, которое нужно записать или прочитать от начала этого блока. Таким образом, диски могут быть разбиты на блоки фиксированного размера и можно непосредственно получить доступ к любому блоку (организовать прямой доступ к файлам).
Непосредственно с устройствами (дисками) взаимодействует часть ОС, называемая системой ввода-вывода (см. лекцию 13). Система ввода-вывода предоставляет в распоряжение более высокоуровневого компонента ОС — файловой системы — используемое дисковое пространство в виде непрерывной последовательности блоков фиксированного размера. Система ввода-вывода имеет дело с физическими блоками диска, которые характеризуются адресом, например диск 2, цилиндр 75, сектор 11. Файловая система имеет дело с логическими блоками, каждый из которых имеет номер (от 0 или 1 до N). Размер логических блоков файла совпадает или является кратным размеру физического блока диска и может быть задан равным размеру страницы виртуальной памяти, поддерживаемой аппаратурой компьютера совместно с операционной системой.
В структуре системы управления файлами можно выделить базисную подсистему, которая отвечает за выделение дискового пространства конкретным файлам, и более высокоуровневую логическую подсистему, которая использует структуру дерева директорий для предоставления модулю базисной подсистемы необходимой ей информации, исходя из символического имени файла. Она также ответственна за авторизацию доступа к файлам .
Стандартный запрос на открытие (open) или создание (create) файла поступает от прикладной программы к логической подсистеме. Логическая подсистема, используя структуру директорий, проверяет права доступа и вызывает базовую подсистему для получения доступа к блокам файла. После этого файл считается открытым, он содержится в таблице открытых файлов, и прикладная программа получает в свое распоряжение дескриптор (или handle в системах Microsoft) этого файла. Дескриптор файла является ссылкой на файл в таблице открытых файлов и используется в запросах прикладной программы на чтение-запись из этого файла. Запись в таблице открытых файлов указывает через систему выделения блоков диска на блоки данного файла. Если к моменту открытия файл уже используется другим процессом, то есть содержится в таблице открытых файлов, то после проверки прав доступа к файлу может быть организован совместный доступ. При этом новому процессу также возвращается дескриптор — ссылка на файл в таблице открытых файлов.

Каталоги, корневой каталог. Дерево каталогов. Каталоги в UNIX.

Каталог (англ. Directory — справочник, указатель) — объект в файловой системе, упрощающий организацию файлов. Типичная файловая система содержит большое количество файлов и каталоги помогают упорядочить её путём их группировки.

В информатике используется следующее определение: каталог — поименованная совокупность байтов на носителе информации, содержащая название подкаталогов и файлов.

Каталог, прямо или косвенно включающий в себя все прочие каталоги и файлы файловой системы, называется корневым. В Unix-подобных ОС он обозначается символом “/” (дробь, слеш), в DOS и Windows исторически используется символ “\” (обратный слеш), но с некоторого времени поддерживается и “/”.

Текущим называется каталог, с которым работает ОС, если ей не указать другого каталога. Он обозначается точкой (.).

Родительским каталогом называется каталог, в котором находится текущий. Он обозначается двумя точками (..).

Каталог, который не является подкаталогом ни одного другого каталога, называется корневым. Это значит, что этот каталог находится на самом верхнем уровне иерархии всех каталогов. В Windows каждый из дисков имеет свой корневой каталог (C:\, D:\ и т.д).

Каталоги в Windows бывают системные (служебные, созданные ОС) и пользовательские (созданные пользователем). Пример системных каталогов: «Рабочий стол», «Корзина», «Сетевое окружение», «Панель управления», каталоги логических дисков и т.п.

Термин папка (англ. folder) был введён для представления объектов файловой системы в графическом пользовательском интерфейсе путём аналогии софисными папками. Он был впервые использован в Mac OS, а в системах семейства Windows — с выходом Windows 95. Эта метафора стала использоваться в большом числе операционных систем: Windows NT, Mac OS, Mac OS X, а также в средах рабочего стола для систем семейства UNIX (например, KDE и GNOME).

В этой терминологии папка, находящаяся в другой папке, называется подпапка, вложенная папка или дочерняя папка. Все вместе папки на компьютере представляют иерархическую структуру (дерево каталогов). Подобная древообразная структура возможна в операционных системах, не допускающих существование «физических ссылок» (Windows 3.x и 9x допускали только аналог символических ссылок — ярлыков). В общем случае файловая система представляет собой ориентированный граф.

Каталог в UNIX — это файл, содержащий несколько inode и привязанные к ним имена. В современных UNIX-подобных ОС вводится структура каталогов, соответствующая стандарту FHS.

Inode, индексный дескриптор — это структура данных в традиционных для ОС UNIX файловых системах, таких как UFS. В этой структуре хранится метаинформация о стандартных файлах, каталогах или других объектах файловой системы, кроме непосредственно данных и имени.

В корневом каталоге ОС UNIX (root) содержится вся иерархия системы. Он не может быть классифицирован, т.к. его подкаталоги могут быть статическими или разделяемыми.

Список главных каталогов и подкаталогов с их классификациями:

· /bin: важнейшие бинарные файлы. Он содержит базовые команды, которые могут использоваться всеми пользователями, и которые являются необходимыми для работы системы: ls, cp, login и др. Статический, неразделяемый.

· /boot: содержит файлы, необходимые для начального загрузчика GNU/Linux (GRUB или LILO для Intel, yaboot для PPC и т.п.). В нем может находится ядро, но если ядро в этом каталоге отсутствует, тогда оно должно быть в корневом каталоге. Статический, неразделяемый.

· /dev: файлы системных устройств (dev от англ. DEVices). Некоторые файлы, находящиеся в /dev, являются обязательными, такие как/dev/null, /dev/zero и /dev/tty. Статический, неразделяемый.

· /etc: содержит все конфигурационные файлы этого компьютера. Этот каталог не может содержать бинарные файлы. Статический, неразделяемый.

· /home: содержит все личные каталоги пользователей системы. Этот каталог может быть разделяемым (в некоторых больших сетях к нему открывается общий доступ через NFS). Конфигурационные файлы ваших любимых приложений (типа почтовых клиентов и браузеров) располагаются в этом каталоге и начинаются с точки («.»). Например, конфигурационные файлы Mozilla находятся в каталоге .mozilla. Переменный, разделяемый.

· /lib: содержит библиотеки, жизненно необходимые для системы; в нем также хранятся модули ядра в подкаталоге /lib/modules/ВЕРСИЯ_ЯДРА. Он содержит все библиотеки, необходимые для работы бинарных файлов из каталогов /bin и /sbin. Также в этом каталоге должны находится: необязательный компоновщик на этапе выполнения или загрузчик ld*, а также динамически подключаемая библиотека Сlibc.so. Статический, неразделяемый.

· /mnt: содержит точки монтирования для временно монтируемых файловых систем, таких как /mnt/cdrom, /mnt/floppy и т.п. Каталог /mntтакже используется для монтирования временных каталогов (карта USB, например, будет примонтирована в /mnt/removable). Переменный, неразделяемый.

· /opt: содержит пакеты не слишком важные для работы системы. Он зарезервирован для дополнительных пакетов; пакеты типа Adobe Acrobat Reader часто устанавливаются в /opt. FHS рекомендует, чтобы статические файлы (бинарники, библиотеки, страницы руководств и т.п.), устанавливаемые в каталог /opt, помещались бы в его подкаталоги /opt/имя_пакета, а их конфигурационные файлы — в /etc/opt.

· /root: домашний каталог root’а. Переменный, неразделяемый.

· /sbin: содержит системные бинарные файлы, необходимые для запуска системы. Большинство этих файлов могут запускаться толькоroot’ом. Обычный пользователь тоже может запустить их, но результат их работы может остаться нулевым. Статический, неразделяемый.

· /tmp: каталог предназначен для хранения временных файлов, которые могут быть создаваны программами. Переменный, неразделяемый.

· /usr: статический, разделяемый.

· /var: место для размещения данных, которые могут изменяться программами в режиме реального времени (такими как почтовые серверы, программы наблюдения, серверы печати и др.). Переменный. Отдельные его подкаталоги могут быть разделяемыми или неразделяемыми.

Узнать еще:

Понятие каталога в информатике

Катало́г — каталог, директория, справочник, папка — объект в файловой системе, упрощающий организацию файлов. Ранее часто использовалось слово директо́рия [1] , которое представляет собой транслитерацию с английского (англ. directory ). Типичная файловая система содержит большое количество файлов, и каталоги помогают упорядочить её путём их группировки. Каталог может быть реализован как специальный файл, где регистрируется информация о других файлах и каталогах на носителе информации [1] .

Содержание

Корневой каталог [ править | править код ]

Каталог, прямо или косвенно включающий в себя все прочие каталоги и файлы файловой системы, называется корневым. В Unix-подобных ОС он обозначается символом / (дробь, слеш), в DOS и Windows исторически используется символ (обратный слеш), но с некоторого времени поддерживается и /.

Текущий каталог [ править | править код ]

Для смены текущего каталога на другой используется команда cd ; без указания целевого каталога она меняет каталог на домашний (в Unix-подобных ОС) или возвращает текущий (в Windows).

Родительский каталог [ править | править код ]

Родительским каталогом называется каталог, в котором находится текущий. Он обозначается двумя точками (..).

Пример (переход в родительский каталог):

Каталоги в UNIX [ править | править код ]

Каталог в UNIX — это файл, содержащий несколько inode и привязанные к ним имена. [2] В современных UNIX-подобных ОС вводится структура каталогов, соответствующая стандарту FHS.

Иерархия каталогов в Windows [ править | править код ]

Термин «Папка» [ править | править код ]

Термин папка (англ. folder ) был введён для представления объектов файловой системы в графическом пользовательском интерфейсе путём аналогии с офисными папками. Он был впервые использован в Mac System Software, предшественнице Mac OS, а в системах семейства Windows — с выходом Windows 95. [3] Эта метафора стала использоваться в большом числе операционных систем: Windows NT, Mac OS, Mac OS X, а также в средах рабочего стола для систем семейства UNIX (например, KDE и GNOME).

До выхода Windows 95 это понятие называлось словами каталог или директория.

В этой терминологии папка, находящаяся в другой папке, называется подпапка, вложенная папка или дочерняя папка. Все вместе папки на компьютере представляют иерархическую структуру (дерево каталогов). Подобная древообразная структура возможна в операционных системах, не допускающих существование «физических ссылок» (таких как Windows 3.x и 9x, которые допускали только ярлыки). В общем случае файловая система представляет собой ориентированный граф.

↑ «Всё суть файлы» // FreeBook, или Введение в POSIX’ивизм
↑ «With the introduction of Windows 95, Microsoft started referring to directories as folders» // Murach’s C# 2005 (англ.) , страница 34

Это заготовка статьи о компьютерах. Вы можете помочь проекту, исправив и дополнив её.

Это примечание по возможности следует заменить более точным.

Wikimedia Foundation . 2010 .

Смотреть что такое «Каталог (файловая система)» в других словарях:

Файловая система — В этой статье не хватает ссылок на источники информации. Информация должна быть проверяема, иначе она может быть поставлена под сомнение и удалена. Вы можете … Википедия

Директория (файловая система) — У этого термина существуют и другие значения, см. Директория. Директория (англ. directory справочник, указатель), син. каталог, папка сущность в файловой системе, упрощающая организацию файлов. Типичная файловая система содержит большое… … Википедия

Папка (файловая система) — Директория (англ. directory справочник, указатель), син. каталог, папка сущность в файловой системе, упрощающая организацию файлов. Типичная файловая система содержит большое количество файлов, и директории помогают упорядочить её путём их… … Википедия

Распределённая файловая система (Microsoft) — Distributed File System (DFS) компонент Microsoft Windows, использующийся для упрощения доступа и управления файлами, физически распределёнными по сети. При её использовании файлы, распределённые по серверам, представляются находящимися в… … Википедия

Каталог — В Викисловаре есть статья «каталог» Катало г (от греч … Википедия

Tree view — Внешний вид tree view Tree view или Outline view (рус. Дерево выбора) элемент (виджет) графического интерфейса пользователя, который представляет собой совокупность связанных отношениями структуры пиктограмм в иерархическом древе. Каждый… … Википедия

Files-11 — (также известна как on disk structure (англ. на дисковая структура) файловая система, используемая в операционной системе OpenVMS, а также в более простой форме в более старой ОС RSX 11. Это иерархическая файловая система с поддержкой… … Википедия

FAT — (англ. File Allocation Table «таблица размещения файлов») классическая архитектура файловой системы, которая из за своей простоты всё ещё широко используется для флеш накопителей. В недавнем прошлом использовалась в дискетах, на… … Википедия

ФС — Файловая система (англ. file system) регламент, определяющий способ организации, хранения и именования данных на носителях информации. Она определяет формат физического хранения информации, которую принято группировать в виде файлов. Конкретная… … Википедия

Ext2 — или 2я расширенная файловая система файловая система для ядра Linux. Она была разработана Rémy Card ом в качестве замены для extended file system. Она достаточно быстра для того, чтобы служить эталоном в тестах производительности файловых… … Википедия

Файл — это определенное количество информации (программа или данные), имеющее имя и хранящееся в долговременной (внешней) памяти. Имя файла состоит из двух частей, разделенных точкой: собственно имя файла и расширение, определяющее его тип (программа, данные и т. д.).

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

Каталог — это группа файлов на одном носителе, объединенных по какому-либо критерию. Каталог имеет имя и может быть зарегистрирован в другом каталоге. Это означает, что он включен в последний как целое и тогда говорят, что он является подчиненным каталогом (подкаталогом)

Структуру каталогов (папок) нередко также называют «деревом каталогов». Правда, «растет» оно не снизу вверх, а сверху вниз, поэтому больше напоминает не систему ветвей, а корневую систему. Каталог самого верхнего уровня в этой системе только один — он называется корневым. У каждого устройства, предназначенного для хранения данных, только один корневой каталог — в него вложены все остальные каталоги. В корневом каталоге могут размещаться также и файлы, хотя это следует считать исключением, а не правилом. Каждому файлу следует находить свое заслуженное место, а корневой каталог замусоривать не надо. В нем операционная система хранит некоторые свои, нужные ей файлы.

Путь (англ. path) — набор символов, показывающий расположение файла в файловой системе, адрес каталога.

Формат файла — спецификация структуры данных, записанных в компьютерном файле. Формат файла часто указывается в его имени, как часть, отделённая точкой; обычно эту часть называют расширением имени файла.Файлы, содержимое которых соответствует одному формату (реже — одному семейству форматов), иногда называют файлами одного типа.

Назначение основных каталогов, директорий, папок в файловой системе Linux

Файловая система Linux представляет собой четкую структуру каталогов и файлов. В этой статье рассмотрим краткое назначение каждого из каталогов.

Файловые системы Linux содержат множество каталогов, большинство из которых определяются стандартом FHS(Filesystem Hierarchy Standard).

Назваие статьи состоит из терминов «каталог», «директория» и «папка». Рассмотрим их.

Каталог или директория (англ. directory — директория) — объект в файловой системе, упрощающий организацию файлов.

Папка (англ. folder) — этот термин используется для представления каталогов в графическом пользовательском интерфейсе.

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

Общая структура файловой системы ОС Linux

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

/
/bin
/boot
cd-rom
/dev
/etc
/home
/lib
/lib64
/lost+found
/media
/mnt
/opt
/proc
/root
/run
/sbin
/selinux
/srv
/sys
/tmp
/usr
/var

/ — корневой каталог

Главный каталог, в нем хранится все, что есть на вашей ОС Linux. Все разделы Linux хранятся в виде другого подкаталога в корневом каталоге /.

/bin — основные бинарные файлы (программы)

Содержит основные двоичные (бинарные) системные программы (модули), утилиты (ls, cp и т.п.) и командные оболочки (bash и т.п.), которые должны обеспечить минимальный уровень работоспособности системы в однопользовательском режиме. Размещение этих файлов в каталоге /bin гарантирует, что в системе эти важные утилиты будут даже в случае, если другие файловые системы не смонтированы.

/boot — файлы для загрузки ОС

Хранятся образы ядер Linux и файлы менеджеров загрузки (grub, lilo и т.д.).

/cdrom – точка монтирования для CD-дисков

Данный каталог не является частью стандарта FHS, содержится в Ubuntu и вышедших из него дистрибутивах. Используется как место для монтируования CD-ROM дисков.

/dev — файлы устройств

В Linux все устройства предоставлены в виде специфических файлов, расположеных в этом каталоге. Например, файл /dev/sda представляет диск SATA. Также в этом каталоге хранятся файлы псевдо-устройств (виртуальных), для этих файлов нет соответствующего реального устройства. Например, файл /dev/random генерирует случайные числа, а файл /dev/null является специальным устройством для удаления всех входных данных.

/etc — конфигурационные файлы

Содержит основные конфигурационные файлы операционной системы и различных программ.

/home — домашние каталоги пользователей

Содержит домашние каталоги пользователей. По идеологии UNIX для обеспечения безопасности ОС рекомендуется хранить пользовательские данные именно в этой директории. Например, если ваше имя пользователя mara, то у вас есть домашний каталог, который находится в /home/mara и содержит пользовательские конфигурационные файлы и личную информацию. Каждый пользователь имеет доступ на запись только в своем домашнем каталоге.

/lib — основные библиотеки

Эта директория предназначена для хранения системных библиотек и компонентов компилятора языка С, необходимых для работы программ из директорий /bin и /sbin и операционной системы в целом.

/lib64 — 64-битные основные библиотеки

Этот каталог присуствует в основном на 64-битных системах, содержит набор библиотек и компонентов компилятора языка С для 64-битных программ.

/lost+found — восстановленные файлы

Присуствует во всех ОС Linux. При сбое в работе файловой системы и дальнейшей проверке файловой системы (при загрузке ОС), все найденные поврежденные файлы будут помещены в каталоге lost+found, их можно попытаться восстановить.

/media — точка для автоматического монтирования

Используемая для автоматического монтирования различных устройств CD-ROM, USB-накопителей и т.д.

/mnt — точка для ручного монтирования

Используется для временного ручного монтирования (с помощю команды mount) различных устройств, таких как CD-ROM, USB-накопителей и т.д.

/opt — вспомогательные пакеты программ

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

/proc – файлы ядра и процессов

В эту директорию примонтирована виртуальная файловая система procfs. В ней находятся специальные файлы, в которых представлена информация о системе и о выполняющихся процессах. Например, в файле /proc/cpuinfo собержиться информация о процессоре.

/root — Домашний каталог пользователя root

Домашний каталог пользователя root. Вместо того, чтобы находиться в /home/root, он помещается в /root для большей надёжности системы.

/run – файлы состояния приложений

Является достаточно новым каталогом, в котором приложениям предоставляется возможность стандартным образом хранить вспомогательные файлы, которые им требуются, например, сокеты и идентификаторы процессов. Эти файлы нельзя хранить в каталоге /tmp, поскольку эти файлы могут быть там удалены.

/sbin — бинарные файлы (программы) для администрирования системы

Каталог /sbin похож на каталог /bin. В нем находятся важные двоичные файлы, которые, как правило, предназначены для их запуска пользователем при администрировании системы.

/selinux – виртуальная файловая система SELinux

В некоторых дистрибутивах (Red Hat, Fedora и т.п) для обеспечения безопасности используется пакет SELinux (Security-Enhanced Linux), при этом создается каталог с файлами /selinux.

/srv – данные сервисных служб

Этот каталог присуствует не во всех дистрибутивах, содержит «данные для сервисов, предоставляемых системой» (например сервер Apache может хранить файлы вашего сайта в этом каталоге). В большинстве случаев директория пуста.

/sys — виртуальная файловая система sysfs

Этот каталог появился с выходом ядра версии 2.6 и в него примонтирована виртуальная файловая система sysfs с информацией об устройствах, драйверах, ядре ОС и т.п.

Описание вложеных каталогов:

/sys/block — содержит директории всех блочных устройств, присутствующих на данный момент в системе.

/sys/bus — содержит список шин, определенных в ядре Linux (eisa, pci и т.д.).

/sys/class — содержит список сгруппированных устройств по классам (printer, scsi-devices и т.д.).

/tmp — временные файлы

Временные файлы, обычно удаляются при перезагрузке системы. Является аналогом C:/Windows/Temp в ОС Windows. Все пользователи имеют права чтения и записи в этом каталоге.

/usr — пользовательские бинарные файлы, используемые только для чтения

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

Описание вложеных каталогов:

/usr/bin — исполняемые файлы для всех учетных записей.

/usr/games — каталог для компьютерных игр в системе.

/usr/include — файлы заголовков, предназначенные для компиляции С-программ.

/usr/lib — системные библиотеки и вспомогательные файлы, расположенные в директории /usr.

/usr/local — в этот каталог устанавливаются приложения, откомпилированные локально, что позволяет им не смешиваться с остальной частью системы.

/usr/local/bin — локальные исполняемые файлы.

/usr/local/etc — локальные системные команды и файлы конфигурации.

/usr/local/lib — локальные вспомогательные файлы.

/usr/local/sbin — локальные служебные системные команды.

/usr/local/src — исходные коды программ каталогов /usr/local/*

/usr/man — страницы интерактивной документации.

/usr/sbin — менее важные команды системного администрирования.

/usr/share — общие данные установленных программ (доступен только для чтения).

/usr/share/man — страницы интерактивной документации.

/usr/share/icons — иконки системы.

/usr/share/doc — справочная документация.

/usr/src — исходные коды нелокальных программных пакетов (например, здесь располагаются исходные кода ядра).

/var — каталог для часто меняющихся данных

В этом каталоге находятся журналы операционной системы, системные log-файлы, cache-файлы и т.д.

/var/adm — журнальные файлы, записи об инсталляции системы, административные компоненты.

/var/cache — все кэши для различных программ.

/var/games — файлы с игровыми достижениями.

/var/log — cистемные журнальные файлы (log-файлы).

/var/lock — лежат lock-файлы, указывающие на занятость некоторого ресурса.

/var/lib — изменяемые программами в процессе работы (например, базы данных, метаданные и др.).

/var/spool — буферные каталоги (например, очереди печати, непрочитанные или не отправленные письма, задачи cron и т.д.).

/var/tmp — каталог для временного хранения файлов.

/var/www — размещаются Web-страницы для сервера Apache.

Посмотреть структуру файловой системы можно используя команду ls -la. Ниже приведен пример вывода команды для дистрибутива OpenSUSE.

[root@linux ~]# ls -la
total 260
drwxr-xr-x  24 root root    4096 Aug 30  2013 .
drwxr-xr-x  24 root root    4096 Aug 30  2013 ..
drwxr-xr-x   2 root root    4096 Aug  8  2012 .config
-rw-r--r--   1 root root  149519 Aug 30  2013 .readahead
drwxr-xr-x   2 root root    4096 Aug  8  2012 bin
drwxr-xr-x   3 root root    4096 Aug  8  2012 boot
drwxr-xr-x  18 root root    3340 May 16 16:29 dev
drwxr-xr-x 122 root root   12288 Jun 27  2013 etc
drwxr-xr-x   4 root root    4096 Sep 21  2012 home
drwxr-xr-x  16 root root    4096 Aug 23  2012 lib
drwxr-xr-x  10 root root   12288 Aug 23  2012 lib64
drwx------   2 root root   16384 Aug  8  2012 lost+found
drwxr-xr-x   2 root root      40 Dec 11  2013 media
drwxr-xr-x   2 root root    4096 Oct 25  2011 mnt
drwxr-xr-x   3 root root    4096 Aug 23  2012 opt
dr-xr-xr-x 194 root root       0 Dec 11  2013 proc
drwx------  31 root root    4096 Jun 10 14:38 root
drwxr-xr-x  23 root root     780 Jul  9 17:39 run
drwxr-xr-x   3 root root   12288 Aug  8  2012 sbin
drwxr-xr-x   2 root root    4096 Oct 25  2011 selinux
drwxr-xr-x   6 1004 users   4096 Sep 21  2012 srv
drwxr-xr-x  12 root root       0 Dec 11  2013 sys
drwxrwxrwt  95 root root    4096 Jul  9 17:39 tmp
drwxr-xr-x  13 root root    4096 Nov 10  2011 usr
drwxr-xr-x  16 root root    4096 Aug  9  2012 var

Вот и все. Рассмотрение предназначения основных встречающихся каталогов в файловой системы Линукс завершено.

18.Основной каталог и подкаталоги, папки.

Каталог — объект в файловой системе, упрощающий организацию файлов. Типичная файловая система содержит большое количество файлов, и каталоги помогают упорядочить её путём их группировки. Каталог — поименованная совокупность байтов на носителе информации, содержащая название подкаталогов и файлов. Каталоги в Windows бывают системные (служебные, созданные ОС) и пользовательские (созданные пользователем). Пример системных каталогов: «Рабочий стол», «Корзина», «Сетевое окружение», «Панель управления», каталоги логических дисков и тому подобные. Иерархия файлов ОС Windows состоит из дисков, директорий (папок) и файлов. У каждого диска также есть свой собственный каталог. Обычно каталог основного диска (который и хранит все системные файлы, необходимые для работы операционной системы) называется «C:\», а буквы «A:\» и «B:\» используются для дисководов гибких дисков. А начиная с каталога с буквой «C:\» идут папки жёстких, логических, сетевых и внешних дисков, приводов оптических дисков и так далее.

Термин папка был введён для представления объектов файловой системы в графическом пользовательском интерфейсе путём аналогии с офисными папками. Он был впервые использован в Mac OS, а в системах семейства Microsoft Windows он появился с выходом Windows 95. В этой терминологии, папка, находящаяся в другой папке, называется подпапка, вложенная папка или дочерняя папка. Все вместе папки на компьютере представляют иерархическую структуру, представляющую собой дерево каталогов.

19.Имена дисковых устройств. Древо файлов, полное имя и путь к файлу.

Иерархия файлов ОС Windows состоит из дисков, директорий (папок) и файлов. У каждого диска также есть свой собственный каталог. Обычно каталог основного диска (который и хранит все системные файлы, необходимые для работы операционной системы) называется «C:\», а буквы «A:\» и «B:\» используются для дисководов гибких дисков. А начиная с каталога с буквой «C:\» идут папки жёстких, логических, сетевых и внешних дисков, приводов оптических дисков и так далее.

Иерархия файлов и папок образуют так называемое «дерево каталогов». Это дерево начинается с корня (корневого, начального каталога в MS-DOS и рабочего стола в Windows.) Это дерево имеет «ветви» – каталоги и «листья» – файлы. Обычно дерево каталогов изображается «перевернутым»: вверху находится корень, а вверху – листья.

Практически во всех операционных системах имя файла составляется из двух частей, разделенных точкой. Например: myprog.pas Слева от точки находится собственно имя файла (myprog). Следующая за точкой часть имени называется расширением файла (pas). Обычно в именах файлов употребляются латинские буквы и цифры. В большинстве ОС максимальная длина расширения — 3 символа. Кроме того, имя файла может и не иметь расширения. В операционной системе Windows в именах файлов допускается использование русских букв; максимальная длина имени — 255 символов.

Расширение указывает, какого рода информация хранится в данном файле. Например, расширение txt обычно обозначает текстовый файл; расширение рсх — графический файл, zip архивный файл, pas — программу на языке Паскаль. Файлы, содержащие выполнимые компьютерные программы, имеют расширения ехе или com.

Путь к файлу — это последовательность, состоящая из имен каталогов, начиная от корневого и заканчивая тем, в котором непосредственно хранится файл. Последовательно записанные имя логического диска, путь к файлу и имя файла составляют полное имя файла. Полные имена некоторых файлов в символике операционных систем MS-DOS и Windows выглядят так:C:\IVANOV\PROGS\progl.pas

Директория что это в компьютере

Директория – это объект в файловой системе компьютера. Это название употреблялось ранее в информатике, сейчас же употребляются слова «каталог» или «папка». Слово произошло от английского – directory. В системе она указывается в виде полного пути к необходимому ярлыку, например, «C:Program FilesMy_Program».

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

Что такое директории установки

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

Разберем на примере: «C:Program FilesGamesНазвание_игры». Это путь к папке в компьютере, которую пользователю необходимо будет открыть, чтобы попасть в то место, куда установлен софт.

А папка с именем «Название_игры» — это и есть тот самый каталог установки. Все они лежат в корне диска С, если не было установлено другое место при инсталляции.

Корневая папка и как ее найти

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

В Виндовс это имена дисков, которые были созданы пользователем на компьютере. Их количество зависит от того, на сколько логических частей разбит физический жесткий диск. Для операционной системы Windows корневым каталогом обычно является диск C (если путь не был изменен при установке системе). Для ОС Linux им будет служить «/». А в ней уже находятся системные файлы и документы.

В отличии от Виндовс в Линуксе всегда один корневой каталог. Для того, чтобы найти его в Виндовс следует открыть ярлык «Мой компьютер» на рабочем столе.

Что такое директория игры

Так называется каталог с установленной игрой. Обычно он хранится на диске C в папке Program Files, но в случае инсталляции в другой каталог расположение изменится.

Как найти директорию

Поиск по ярлыку

Путь к месту где расположена нужная программа или игра можно отыскать несколькими способами. Например, по ярлыку:

кликаете правой клавишей мышки (ПКМ) по ярлыку программы на рабочем столе;
в открывшемся окне выбираете расположение файла и кликаете по нему левой кнопкой мыши (ЛКМ). В Windows 7 и старше найти это пункт можно в свойствах ярлыка;
откроется окно с искомым содержимым. Сверху, в строке поиска, будет указан путь расположения утилиты.

Поиск по умолчанию

Для поиска можно использовать стандартные средства ОС:

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

Поиск на компьютере

Третьим способом будет поиск на компьютере. Заходите в «Мой компьютер», открываете диск С, в правом верхнем углу вводите название в строку поиска и ищете необходимые файлы в папках. Это отнимет больше времени, нежели использование первых двух способов, поскольку система проводит анализ всех элементов попадающих в отбор.

Как создать каталог на компьютере

Для создания каталога на компьютере необходимо сделать следующее:

в любом месте на компьютере кликнуть правой кнопкой мыши и в контекстном меню выбрать «Создать», а затем «Папку»;
на рабочем столе отобразится «Новая папка», которой можно задать любое имя;
кликните по кнопке «Enter» на клавиатуре;
каталог создан.

Свойства папки

Каждая папка имеет свои свойства — ее можно скрывать от пользователей, защищать от копирования, случайного изменения. Если кликнуть на нее правой клавишей мыши и выбрать «Свойства», то можно увидеть полезную информацию: занимаемый объем, место расположения, дату создания, а также сколько подпапок и файлов она содержит.

Вкладка «Настройка» отвечает за внешний вид, а «Доступ» и «Безопасность» позволяют включать (расшаривать) доступ по сети и задавать права на использование другим локальным и сетевым пользователям.

Основные операции

Существует ряд стандартных операций, которые можно производить над папками:

Копирование. Для этого, кликаете по папке правой кнопкой мыши и выбираете пункт «Копировать». Открываете расположение в которое необходимо произвести копирование. В открывшемся окне кликаете правой кнопкой мыши и выбираете пункт «Вставить».
Удаление. Кликаете по объекту ПКМ и находите пункт «Удалить». Нажимаете на него. Потом подтверждаете действие, кликнув по кнопке «Ок». Она удалится в корзину.
Перемещение. Перейдите к расположению целевой папки, откройте место, куда необходимо ее перетащить, наведите курсор на папку и зажмите ПКМ. Перетащите в открытое окно, и отпустите кнопку мыши, в меню следует выбрать «перемещение». Эта операция идентична команде «Вырезать», но в этом случае нужно в контекстом меню, по нажатию правой клавиши мыши выбрать «Вырезать». А в расположении, куда вставляем каталог – «Вставить».
Переименование. Кликаете по объекту ПКМ, выбираете пункт «Переименовать». Вписываете название и нажимаете «Enter».
Открытие. Папки можно открывать для работы и перемещения в них других объектов. Дважды кликните по ней ЛКМ и она откроется.

Содержание

Корневой каталог [ править | править код ]

Текущий каталог [ править | править код ]

Родительский каталог [ править | править код ]

Родительским каталогом называется каталог, в котором находится текущий. Он обозначается двумя точками (..).

Пример (переход в родительский каталог):

Каталоги в UNIX [ править | править код ]

Иерархия каталогов в Windows [ править | править код ]

Термин «Папка» [ править | править код ]

До выхода Windows 95 это понятие называлось словами каталог или директория.

Достаточно часто многие пользователи сталкиваются с понятием директории. Некоторые, услышав вопрос: «Директория – это что такое?», недоуменно пожимают плечами, хотя каждый человек, работающий с компьютером, сталкивается с этим каждый день. Но давайте рассмотрим суть вопроса несколько подробнее.

Компьютерная терминология: директория – это…

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

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

Файловая система и принципы упорядочивания файлов

Папка, директория или каталог – понятия достаточно условные. Дело в том, что физически на жестком диске или любом съемном носителе такой элемент не присутствует, в отличие даже от файла с нулевым размером. Таким образом, директория – это элемент, если можно так выразиться, виртуальный. Собственного места на диске папка, в которой отсутствуют файлы, не занимает абсолютно никакого. Если же в ней что-то есть, виртуальный объем занимаемой дисковой памяти полностью совпадает с суммарным размером всех объектов, находящихся внутри нее. Но за существование директории отвечает специальный файл без расширения, в котором хранится информация об объектах, их количестве, дате создания или изменения, размере и т. д.

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

В реальной жизни можно провести аналогичное сравнение. По сути, директория – это некий виртуальный ящик, в который пользователь складывает нужные ему вещи (в данном случае – файлы). Вот и получается, что документы не разбросаны по всему винчестеру (хотя физически так оно и есть), а находятся в строго определенных местах. Такое четкое упорядочивание в считанные минуты позволяет найти нужный объект. Само собой разумеется, что папки имеют свои названия.

Самый простой пример – стандартная директория «Мои документы». Понятно, что пользователь собственные файлы будет искать именно здесь, поскольку, как правило, в другое место для удобства их и не помещает. Кроме того, Windows-системы, например, изначально предлагают пользователю специализированные каталоги для хранения информации определенного типа («Моя музыка», «Мои видеозаписи» и т. д.). Естественно, их использование обязательным не является. С другой стороны, если пользоваться именно ими, всегда будешь точно знать, где и что находится.

Просмотр папок в файловых менеджерах

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

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

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

Это еще больше упрощает дело. Допустим, пользователь для папки «Музыка» устанавливает иконку с музыкальными нотами. Даже не обращая внимания на название, он сразу же видит, что это именно музыка, а не что-то другое.

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

Отображение скрытых объектов

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

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

Простейшие операции с папками

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

Создание директорий тоже сложности не представляет. Например, в том же «Проводнике» достаточно кликнуть правой кнопкой мыши на пустой области рабочей зоны и вызвать соответствующую команду. После этого будет создан новый каталог с названием «Новая папка» по умолчанию. Естественно, это не единственный способ. Можно использовать команды основного меню, специальные кнопки панели или стандартное сочетание Ctrl + Shift + N. А вообще, для разных файловых менеджеров существуют свои методы.

Директории сайтов

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

Прежде всего, в корневом каталоге в обязательном порядке должен находиться файл Index.html (главная страница), туда же загружаются папки Content (для страниц) и Images (для картинок). Впрочем, необязательно использовать именно такие названия. Их можно обозначить как угодно – допустим, давать наименования по рубрикам, в которые будут помещаться материалы по определенной тематике. Правда, это увеличит сам корневой каталог, зато в некоторых случаях именно за счет этого можно добиться сокращения пути к самим страницам.

Заключение

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

Создание каталогов в windows

Каталоги (папки) — важные элементы иерархической структуры, необходимые для обеспечения удобного доступа к файлам, если файлов на носителе слишком много. Файлы объединяются в каталоги. Каталоги низких уровней вкладываются в каталоги более высоких уровней и являются для них вложенными. Верхним уровнем вложенности иерархической структуры является корневой каталог диска.

До появления операционной системы Windows 95 при описании иерархической файловой структуры использовался введенный выше термин каталог. С появлением этой системы был введен новый термин — папка. В том, что касается обслуживания файловой структуры носителя данных, эти термины равнозначны: каждому каталогу файлов на диске соответствует одноименная папка операционной системы. Основное отличие понятий папка и каталог проявляется не в организации хранения файлов, а в организации хранения объектов иной природы. Так, например, в операционных системах семейства Windows существуют специальные папки, представляющие собой удобные логические структуры, которым не соответствует ни один каталог диска.

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

Дерево файлов (дерево каталогов, папок) – структура каталогов, подкаталогов и файлов на диске, указывающая расположение файлов в каталогах и подкаталогах, подкаталогов в каталогах. Логическая подчиненность графически изображается деревом с одной вершиной, называемой корневым каталогом, или папкой диска, и ветвлением. В каждую точку ветвления (папку) входит только одна ветвь от «родительского» каталога, а выходить могут несколько. При переходе к подчиненным папкам вниз ветви только расходятся и никогда не пересекаются.

Путь к файлу — указание диска и последовательности папок (каталогов) до папки, которая открывает доступ к файлу. Путь начинается от значка с именем диска (верхний уровень), который открывает корневую папку диска и обозначается буквой с двоеточием (например. Диск С:) и идет вниз по дереву папок. При записи последовательность папок перечисляется через косую черту ( — обратный слеш).

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

Не нашли то, что искали? Воспользуйтесь поиском:

Содержание

Корневой каталог [ править | править код ]

Текущий каталог [ править | править код ]

Родительский каталог [ править | править код ]

Родительским каталогом называется каталог, в котором находится текущий. Он обозначается двумя точками (..).

Пример (переход в родительский каталог):

Каталоги в UNIX [ править | править код ]

Иерархия каталогов в Windows [ править | править код ]

Термин «Папка» [ править | править код ]

До выхода Windows 95 это понятие называлось словами каталог или директория.

Создание каталогов (папок) и загрузка файлов

Создаем папки и директории для файлов

1. Откройте окно «Мой компьютер»

2. Создайте каталог(новую папку) в корне диска C: с названием mymoodle.

Создание новой папки (каталога): двойным щелчком мышки открыть раздел C: жесткого диска >> в свободном месте окна кликнуть правой кнопкой мышки >> в выпадающем списке выбрать пункт «Создать» >> в следующем выпадающем списке выбрать пункт «Папку»

Переименование папки(каталога): название папки можно ввести сразу после создания, или после кликнуть на выделенной «Новой папке» правой кнопкой мышки >> из выпадающего списка выбрать пункт «Переименовать» >> ввести своё имя папки

Важно! Для удобства установки рекомендуется название папки mymoodle, и расположена она должна быть обязательно в корневом каталоге C: – в котором установлена операционная система компьютера. В этом случае полный путь к этому каталогу будет таким: C:mymoodle и при установке Moodle Вам не придется вводить его вручную.

3. Скачайте архив с последней версией Moodle для Windows с официального сайта – //download.moodle.org/windows/

4. Распакуйте скачанный архив MoodleWindowsInstaller-latest.zip в созданный ранее каталог C:mymoodle

Распаковка архива в папку: откройте zip-архив программой WinRAR или аналогичной >> кликните пункт меню программы «Извлечь» >>

>> укажите папку, в которую необходимо распаковать архив. У нас это C:mymoodle

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

Файловая система обеспечивает постоянное хранение файлов данных, приложений и файлов, связанных с самой операционной системой. Следовательно, файловая система является одним из основных ресурсов, используемых всеми процессами.

APFS — файловая система по умолчанию в macOS, iOS, watchOS и tvOS. APFS заменяет HFS + в качестве файловой системы по умолчанию для iOS 10.3 и новее, а также macOS High Sierra и новее. macOS дополнительно поддерживает множество других форматов, как описано в разделе Поддерживаемые файловые системы.

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

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

О файловой системе iOS

Файловая система iOS ориентирована на приложения, работающие самостоятельно. Для упрощения системы пользователи устройств iOS не имеют прямого доступа к файловой системе, и ожидается, что приложения будут следовать этому соглашению.

Стандартные каталоги iOS: где находятся файлы

В целях безопасности взаимодействие приложения iOS с файловой системой ограничено каталогами внутри каталога песочницы приложения. Во время установки нового приложения установщик создает несколько каталогов контейнеров для приложения внутри каталога песочницы.Каждый каталог контейнера имеет определенную роль. Каталог контейнера пакета содержит пакет приложения, тогда как каталог контейнера данных содержит данные как для приложения, так и для пользователя. Каталог контейнера данных дополнительно разделен на несколько подкаталогов, которые приложение может использовать для сортировки и организации своих данных. Приложение также может запрашивать доступ к дополнительным каталогам контейнеров, например контейнеру iCloud, во время выполнения.

Эти каталоги контейнеров составляют основное представление файловой системы приложения.На рис. 1-1 показано представление каталога песочницы для приложения.

Рисунок 1-1 Приложение iOS, работающее в собственном каталоге песочницы

Как правило, приложению запрещен доступ или создание файлов за пределами его каталогов-контейнеров. Одно исключение из этого правила — когда приложение использует общедоступные системные интерфейсы для доступа к таким вещам, как контакты пользователя или музыка. В этих случаях системные платформы используют вспомогательные приложения для обработки любых связанных с файлами операций, необходимых для чтения или изменения соответствующих хранилищ данных.

В таблице 1-1 перечислены некоторые из наиболее важных подкаталогов внутри каталога песочницы и описано их предполагаемое использование. В этой таблице также описаны любые дополнительные ограничения доступа для каждого подкаталога и указано, выполняется ли резервное копирование содержимого каталога с помощью iTunes и iCloud.

**Таблица 1-1** Обычно используемые каталоги приложения iOS
Каталог	Описание
AppName `.app`	Это пакет приложения. Этот каталог содержит приложение и все его ресурсы. Вы не можете писать в этот каталог. Во избежание взлома каталог пакета подписывается во время установки. Запись в этот каталог изменяет подпись и предотвращает запуск вашего приложения. Однако вы можете получить доступ только для чтения к любым ресурсам, хранящимся в пакете приложений. Для получения дополнительной информации см. Руководство по программированию ресурсов Содержимое этого каталога не копируется iTunes или iCloud.Однако iTunes выполняет первоначальную синхронизацию любых приложений, приобретенных в App Store.
`Documents /`	Используйте этот каталог для хранения пользовательского контента. Содержимое этого каталога может быть доступно пользователю через общий доступ к файлам; следовательно, этот каталог должен содержать только файлы, которые вы можете захотеть предоставить пользователю. Содержимое этого каталога зарезервировано iTunes и iCloud.
`Documents / Inbox`	Используйте этот каталог для доступа к файлам, которые вашему приложению было предложено открыть внешними объектами.В частности, программа Mail помещает в этот каталог вложения электронной почты, связанные с вашим приложением. Контроллеры взаимодействия с документами также могут размещать в нем файлы. Ваше приложение может читать и удалять файлы в этом каталоге, но не может создавать новые файлы или записывать в существующие файлы. Если пользователь пытается отредактировать файл в этом каталоге, ваше приложение должно незаметно переместить его из каталога, прежде чем вносить какие-либо изменения. Содержимое этого каталога зарезервировано iTunes и iCloud.
`Библиотека /`	Это каталог верхнего уровня для всех файлов, не являющихся файлами данных пользователя.Обычно вы помещаете файлы в один из нескольких стандартных подкаталогов. Приложения iOS обычно используют подкаталоги `Application Support` и `Caches` ; однако вы можете создавать собственные подкаталоги. Используйте подкаталоги библиотеки для любых файлов, которые вы не хотите показывать пользователю. Ваше приложение не должно использовать эти каталоги для файлов пользовательских данных. Резервное копирование содержимого каталога `Library` (за исключением подкаталога `Caches` ) выполняется iTunes и iCloud. Дополнительные сведения о каталоге библиотеки и его часто используемых подкаталогах см. В разделе Каталог библиотеки, в котором хранятся файлы, относящиеся к приложениям.
`tmp /`	Используйте этот каталог для записи временных файлов, которые не должны сохраняться между запусками вашего приложения. Ваше приложение должно удалить файлы из этого каталога, когда они больше не нужны; однако система может очистить этот каталог, когда ваше приложение не запущено. Содержимое этого каталога не поддерживается iTunes или iCloud.

Приложение iOS может создавать дополнительные каталоги в каталогах Documents , Library и tmp . Вы можете сделать это, чтобы лучше организовать файлы в этих местах.

Для получения информации о том, как получить ссылки на предыдущие каталоги из вашего приложения iOS, см. Поиск элементов в стандартных каталогах. Советы о том, куда помещать файлы, см. В разделе Где следует размещать файлы приложения.

Где следует размещать файлы приложения

Чтобы процессы синхронизации и резервного копирования на устройствах iOS не занимали много времени, выбирайте место размещения файлов избирательно. Приложения, в которых хранятся большие файлы, могут замедлить процесс резервного копирования в iTunes или iCloud. Эти приложения также могут потреблять большой объем доступного хранилища пользователя, что может побудить пользователя удалить приложение или отключить резервное копирование данных этого приложения в iCloud. Имея это в виду, вы должны хранить данные приложения в соответствии со следующими рекомендациями:

Поместите данные пользователя в Documents / .Пользовательские данные обычно включают в себя любые файлы, которые вы можете захотеть предоставить пользователю — все, что вы можете пожелать создать, импортировать, удалить или отредактировать. Для приложения для рисования пользовательские данные включают любые графические файлы, которые пользователь может создать. Для текстового редактора он включает текстовые файлы. Видео- и аудиоприложения могут даже включать файлы, которые пользователь загрузил для просмотра или прослушивания позже.
Поместите файлы поддержки, созданные приложением, в каталог Library / Application support / . Как правило, этот каталог включает файлы, которые приложение использует для запуска, но которые должны оставаться скрытыми от пользователя.Этот каталог также может включать файлы данных, файлы конфигурации, шаблоны и измененные версии ресурсов, загруженные из пакета приложения.
Помните, что файлы в Documents / и Application Support / создаются по умолчанию. Вы можете исключить файлы из резервной копии, вызвав - [NSURL setResourceValue: forKey: error:] с помощью ключа NSURLIsExcludedFromBackupKey . Любой файл, который можно воссоздать или загрузить, необходимо исключить из резервной копии.Это особенно важно для больших медиафайлов. Если ваше приложение загружает видео или аудио файлы, убедитесь, что они не включены в резервную копию.
Поместите временные данные в каталог tmp / . Временные данные включают в себя любые данные, которые не нужно хранить в течение длительного периода времени. Не забудьте удалить эти файлы, когда закончите с ними, чтобы они больше не занимали место на устройстве пользователя. Система будет периодически очищать эти файлы, когда ваше приложение не работает; поэтому вы не можете полагаться на то, что эти файлы сохранятся после завершения работы вашего приложения.
Поместите файлы кэша данных в каталог Library / Caches / . Данные кэша могут использоваться для любых данных, которые должны храниться дольше временных данных, но не так долго, как файл поддержки. Вообще говоря, приложение не требует данных кэша для правильной работы, но оно может использовать данные кэша для повышения производительности. Примеры данных кэша включают (но не ограничиваются ими) файлы кэша базы данных и временный загружаемый контент. Обратите внимание, что система может удалить каталог Caches / , чтобы освободить место на диске, поэтому ваше приложение должно иметь возможность повторно создавать или загружать эти файлы по мере необходимости.

О файловой системе macOS

Файловая система macOS разработана для компьютеров Mac, где и пользователи, и программное обеспечение имеют доступ к файловой системе. Пользователи получают доступ к файловой системе напрямую через Finder, который представляет собой ориентированный на пользователя вид файловой системы, скрывая или переименовывая некоторые файлы и каталоги. Приложения получают доступ к файловой системе с помощью системных интерфейсов, которые показывают полную файловую систему в том виде, в котором она отображается на диске.

Домены определяют размещение файлов

В macOS файловая система разделена на несколько доменов, которые разделяют файлы и ресурсы в зависимости от их предполагаемого использования.Такое разделение обеспечивает простоту для пользователя, которому нужно беспокоиться только о конкретном подмножестве файлов. Упорядочивание файлов по доменам также позволяет системе применять общие права доступа к файлам в этом домене, предотвращая намеренное или случайное изменение файлов неавторизованными пользователями.

Пользовательский домен содержит ресурсы, относящиеся к пользователям, которые входят в систему. Хотя технически он охватывает всех пользователей, этот домен отражает только домашний каталог текущего пользователя во время выполнения.Домашние каталоги пользователей могут находиться на загрузочном томе компьютера (в каталоге / Users ) или на сетевом томе. Каждый пользователь (независимо от привилегий) имеет доступ и контроль над файлами в своем собственном домашнем каталоге.
Локальный домен содержит ресурсы, такие как приложения, которые являются локальными для текущего компьютера и совместно используются всеми пользователями этого компьютера. Локальный домен не соответствует одному физическому каталогу, а вместо этого состоит из нескольких каталогов на локальном загрузочном (и корневом) томе.Этот домен обычно управляется системой, но пользователи с административными привилегиями могут добавлять, удалять или изменять элементы в этом домене.
Сетевой домен содержит ресурсы, такие как приложения и документы, которые совместно используются всеми пользователями локальной сети. Элементы в этом домене обычно расположены на сетевых файловых серверах и находятся под контролем сетевого администратора.
Системный домен содержит системное программное обеспечение, установленное Apple.Ресурсы в системном домене необходимы системе для работы. Пользователи не могут добавлять, удалять или изменять элементы в этом домене.

На рис. 1-2 показано, как локальный, системный и пользовательский домены сопоставляются с локальной файловой системой установки macOS. (Сетевой домен не показан, но во многом похож на локальный домен.) На этом рисунке показаны видимые каталоги, которые может видеть пользователь. В зависимости от системы пользователя другие каталоги могут быть видны или некоторые из показанных здесь могут быть скрыты.

Рисунок 1-2 Локальная файловая система macOS

Для получения информации о содержимом каталогов в macOS см. Стандартные каталоги macOS: где находятся файлы. Для получения информации о каталогах, которые macOS обычно скрывает от пользователя (и почему), см. Скрытые файлы и каталоги: упрощение взаимодействия с пользователем.

Стандартные каталоги macOS: где находятся файлы

Независимо от того, предоставлены ли они системой или созданы вашим приложением, каждый файл имеет свое место в macOS.В таблице 1-2 перечислены некоторые из каталогов верхнего уровня в установке macOS и типы содержимого, которые каждый из них содержит.

**Таблица 1-2** Обычно используемые каталоги в macOS
Каталог	Использование
`/ Applications`	В этом каталоге вы устанавливаете приложения, предназначенные для использования всеми пользователи компьютера. Магазин приложений автоматически устанавливает приложения, приобретенные пользователем, в этот каталог. Подкаталог `Utilities` содержит подмножество приложений, которые предназначены для использования в управлении локальной системой. Этот каталог является частью локального домена.
`Библиотека`	В системе имеется несколько каталогов `Library` , каждый из которых связан с отдельным доменом или конкретным пользователем. Приложения должны использовать каталог `Library` для хранения специфичных для приложения (или специфичных для системы) ресурсов. Для получения подробной информации о содержимом этого каталога и о том, как вы его используете для поддержки своих приложений, см. Каталог библиотек, в котором хранятся файлы, относящиеся к конкретным приложениям.
`/ Сеть`	Этот каталог содержит список компьютеров в локальной сети. Нет гарантии, что файлы, расположенные на сетевых файловых серверах, будут иметь каталог `/ Network` в начале своего пути. Имена путей различаются в зависимости от нескольких факторов, включая способ монтирования сетевого тома.Например, если пользователь использует команду «Подключиться к серверу» для монтирования тома, пути начинаются с каталога `/ Volumes` . При написании кода предполагайте, что файлы на любом томе, кроме загрузочного, могут быть расположены на сетевом сервере.
`/ System`	Этот каталог содержит системные ресурсы, необходимые для работы macOS. Эти ресурсы предоставлены Apple и не могут быть изменены. Этот каталог содержит содержимое системного домена.
`/ Пользователи`	Этот каталог содержит один или несколько домашних каталогов пользователей. В домашнем каталоге пользователя хранятся файлы, связанные с пользователем. Обычный домашний каталог пользователя включает следующие подкаталоги: `Applications` — содержит приложения для конкретного пользователя. `Рабочий стол` — содержит элементы на рабочем столе пользователя. `Документы` — содержит пользовательские документы и файлы. `Загрузки` —Содержит файлы, загруженные из Интернета. `Библиотека` — содержит файлы приложений для конкретного пользователя (скрытые в macOS 10.7 и более поздних версиях). `Фильмы` — содержит видеофайлы пользователя. `Музыка` — содержит музыкальные файлы пользователя. `Изображения` — содержит фотографии пользователя. `Общедоступный` — Содержит контент, которым пользователь хочет поделиться. `Сайты` — содержит веб-страницы, используемые личным сайтом пользователя. (Для отображения этих страниц необходимо включить общий доступ к Интернету.) Предыдущие каталоги предназначены только для хранения пользовательских документов и носителей. Приложения не должны записывать файлы в предыдущие каталоги, если это явно не указано пользователем. Единственным исключением из этого правила является каталог `Library` , который приложения могут использовать для хранения файлов данных, необходимых для поддержки текущего пользователя. Из подкаталогов только каталог `Public` доступен другим пользователям в системе. Доступ к другим каталогам по умолчанию ограничен.

Важно: Файлы в каталогах пользователя Documents и Desktop должны отражать только те документы, которые пользователь создал и с которыми напрямую работает. Точно так же каталоги мультимедиа должны содержать только мультимедийные файлы пользователя. Эти каталоги никогда не должны использоваться для хранения файлов данных, которые ваше приложение создает и управляет автоматически.Если вам нужно место для хранения автоматически сгенерированных файлов, используйте каталог Library , который предназначен специально для этой цели. Для получения информации о том, куда помещать файлы в каталог библиотеки, см. Каталог библиотеки, в котором хранятся файлы, относящиеся к приложениям.

Хотя каталоги в Табл. 1-2 видны пользователям macOS, это не единственные каталоги, присутствующие в файловой системе. macOS скрывает многие каталоги, чтобы предотвратить доступ пользователей к файлам, которые им не нужны.

Изолированные контейнеры файлов приложений macOS

изолированные приложения macOS имеют все свои Application Support , Cache , временные каталоги и другие связанные документы, хранящиеся в каталоге, расположенном по определенному системой пути, который можно получить, вызвав NSHomeDirectory функция.

Для получения дополнительной информации см. App Sandbox Design Guide .

Скрытые файлы и каталоги: упрощение взаимодействия с пользователем

Чтобы упростить работу для пользователей, Finder и некоторые определенные пользовательские интерфейсы (например, панели «Открыть» и «Сохранить»), скройте многие файлы и каталоги, которые пользователь никогда не должен придется использовать.Многие из скрытых элементов являются ресурсами системы или приложения, к которым пользователи не могут (или не должны) обращаться напрямую. Среди скрытых файлов и каталогов следующие:

Точечные каталоги и файлы. Любой файл или каталог, имя которого начинается с символа точки (. ), автоматически скрывается. Это соглашение взято из UNIX, которая использовала его для сокрытия системных сценариев и других специальных типов файлов и каталогов. Два специальных каталога в этой категории — это .Каталоги и .. , которые являются ссылками на текущий и родительский каталоги соответственно.
Каталоги, относящиеся к UNIX. Каталоги в этой категории унаследованы от традиционных установок UNIX. Они являются важной частью уровня BSD системы, но более полезны для разработчиков программного обеспечения, чем для конечных пользователей. Некоторые из наиболее важных скрытых каталогов включают:
- / bin — Содержит важные двоичные файлы командной строки.Обычно эти двоичные файлы выполняются из сценариев командной строки.
- / dev —Содержит важные файлы устройств, например точки монтирования для подключенного оборудования.
- / etc —Содержит файлы конфигурации для конкретного хоста.
- / sbin —Содержит важные системные двоичные файлы.
- / tmp —Содержит временные файлы, созданные приложениями и системой.
- / usr —Содержит второстепенные двоичные файлы командной строки, библиотеки, файлы заголовков и другие данные.
- / var —Содержит файлы журналов и другие файлы с переменным содержанием. (Файлы журнала обычно просматриваются с помощью приложения Console.)
Явно скрытые файлы и каталоги. Finder может скрывать определенные файлы или каталоги, к которым пользователь не должен обращаться напрямую. Наиболее ярким примером этого является каталог / Volumes , который содержит подкаталог для каждого смонтированного диска в локальной файловой системе из командной строки.(Finder предоставляет другой пользовательский интерфейс для доступа к локальным дискам.) В macOS 10.7 и более поздних версиях Finder также скрывает каталог ~ / Library , то есть каталог Library , расположенный в домашнем каталоге пользователя.
Пакеты и связки. Пакеты и бандлы — это каталоги, которые Finder представляет пользователю, как если бы они были файлами. Пакеты скрывают внутреннюю работу исполняемых файлов, таких как приложения, и просто представляют собой единый объект, который можно легко перемещать по файловой системе.Точно так же пакеты позволяют приложениям реализовывать сложные форматы документов, состоящие из нескольких отдельных файлов, при этом представляя пользователю то, что кажется одним документом.

Хотя Finder и другие системные интерфейсы скрывают файлы и каталоги от пользователя, интерфейсы Какао, такие как NSFileManager , не отфильтровывают файлы или каталоги, которые обычно невидимы для пользователей. Таким образом, код, использующий эти интерфейсы, теоретически имеет полное представление о файловой системе и ее содержимом.(Конечно, процесс действительно имеет доступ только к тем файлам и каталогам, для которых у него есть соответствующие разрешения.)

Файлы и каталоги могут иметь альтернативные имена

В некоторых ситуациях Finder представляет пользователям имена файлов или каталогов, которые не соответствуют совпадают с реальными именами, как они появляются в файловой системе. Эти имена известны как отображаемые имена и используются только Finder и конкретными компонентами системы (такими как панели «Открыть» и «Сохранить») при представлении пользователю информации о файлах и каталогах.Отображаемые имена улучшают взаимодействие с пользователем, представляя пользователю контент в более удобной форме. Например, macOS использует отображаемые имена в следующих ситуациях:

Локализованные имена. Система предоставляет локализованные имена для многих системных каталогов, таких как Applications , Library , Music , Movies . Аналогичным образом приложение может предоставлять локализованные имена для себя и для любых создаваемых им каталогов.
Расширение имени файла скрыто. По умолчанию система скрывает расширения файлов для всех файлов. Пользователь может изменить параметр, но когда действует скрытие расширения имени файла, символы после последней точки в имени файла (и сама точка) не отображаются.

Отображаемые имена не влияют на фактическое имя файла в файловой системе. Код, который обращается к файлу или каталогу программно, должен указывать фактическое имя элемента при открытии или управлении элементом с помощью интерфейсов файловой системы.Единственный раз, когда ваше приложение должно использовать отображаемые имена, — это когда пользователю отображается имя файла или каталога. Вы можете получить отображаемое имя для любого файла или каталога, используя метод displayNameAtPath: из NSFileManager .

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

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

В каталоге библиотеки хранятся файлы, относящиеся к приложениям.

В каталоге библиотеки приложения и другие модули кода хранят свои пользовательские файлы данных. Независимо от того, пишете ли вы код для iOS или macOS, важно понимать структуру каталога Library . Вы используете этот каталог для хранения файлов данных, кешей, ресурсов, настроек и даже пользовательских данных в некоторых конкретных ситуациях.

В системе есть несколько каталогов Library , но только некоторые из них, к которым ваш код должен когда-либо обращаться:

Library в текущем домашнем каталоге — это версия каталога, которую вы используете чаще всего, потому что это тот, который содержит все пользовательские файлы. В iOS библиотека помещается в пакет данных приложений. В macOS это каталог изолированной программной среды приложения или домашний каталог текущего пользователя (если приложение не находится в изолированной программной среде).
/ Библиотека (только для macOS) — приложения, которые совместно используют ресурсы между пользователями, хранят эти ресурсы в этой версии каталога библиотеки . Изолированным приложениям не разрешено использовать этот каталог.
/ System / Library (только для macOS) — этот каталог зарезервирован для использования Apple.

После выбора используемой версии каталога библиотеки вам все равно нужно знать, где хранить файлы. Сам каталог библиотеки содержит несколько подкаталогов, которые подразделяют контент, специфичный для приложения, на несколько хорошо известных категорий.В Табл. 1-3 перечислены наиболее распространенные подкаталоги, которые вы можете использовать. Хотя каталоги библиотеки в macOS содержат намного больше подкаталогов, чем перечисленные, большинство из них используется только системой. Если вам нужен более полный список подкаталогов, см. Сведения о каталоге библиотеки macOS.

**Таблица 1-3** Ключевые подкаталоги библиотеки `Каталог`
Каталог	Использование
`Поддержка приложений`	Используйте этот каталог для хранения всех файлов данных приложений кроме тех, которые связаны с документами пользователя.Например, вы можете использовать этот каталог для хранения файлов данных, созданных приложением, файлов конфигурации, шаблонов или других фиксированных или изменяемых ресурсов, которыми управляет приложение. Приложение может использовать этот каталог для хранения изменяемой копии ресурсов, изначально содержащихся в пакете приложения. Игра может использовать этот каталог для хранения новых уровней, приобретенных пользователем и загруженных с сервера. Все содержимое этого каталога должно быть помещено в настраиваемый подкаталог, имя которого совпадает с идентификатором пакета вашего приложения или вашей компании. В iOS содержимое этого каталога копируется iTunes и iCloud.
`Кеши`	Используйте этот каталог для записи любых файлов поддержки для конкретного приложения, которые ваше приложение может легко воссоздать. Ваше приложение обычно отвечает за управление содержимым этого каталога, а также за добавление и удаление файлов по мере необходимости. В iOS 2.2 и новее содержимое этого каталога не копируется iTunes или iCloud.Кроме того, система удаляет файлы в этом каталоге при полном восстановлении устройства. В iOS 5.0 и более поздних версиях система может удалить каталог `Caches` в редких случаях, когда в системе очень мало места на диске. Этого никогда не произойдет, пока приложение работает. Однако имейте в виду, что восстановление из резервной копии не обязательно является единственным условием, при котором каталог Caches может быть удален.
`Фреймворки`	В macOS фреймворки, которые должны совместно использоваться несколькими приложениями, могут быть установлены либо в локальном, либо в пользовательском домене.В каталоге Frameworks в системном домене хранятся платформы, которые вы используете для создания приложений macOS. В iOS приложения не могут устанавливать пользовательские платформы.
`Настройки`	Этот каталог содержит файлы настроек для конкретных приложений. Вам не следует создавать файлы в этом каталоге самостоятельно. Вместо этого используйте `NSUserDefaults` class или CFPreferences API, чтобы получить и установить значения предпочтений для вашего приложения. В iOS содержимое этого каталога копируется iTunes и iCloud.

Контейнер для хранения файлов iCloud

iCloud предоставляет структурированную систему для хранения файлов для приложений, использующих iCloud:

Приложения имеют основной каталог контейнера iCloud для хранения собственных файлов. Они также могут получить доступ к вторичным каталогам контейнеров iCloud, указанным в их правах на приложения.
Внутри каждого каталога контейнера файлы разделены на «документы» и данные. Каждый файл или пакет файлов, расположенный в подкаталоге Documents (или одном из его подкаталогов), представляется пользователю (через пользовательский интерфейс iCloud в macOS и iOS) как отдельный документ, который можно удалить по отдельности.Все, что отсутствует в Documents или в одном из его подкаталогов, обрабатывается как данные и отображается как отдельная запись в пользовательском интерфейсе iCloud.

Документы, которые пользователь создает и видит в пользовательском интерфейсе приложения — например, браузеры документов в Pages, Numbers и Keynote должны храниться в каталоге Documents . Другой пример файлов, которые могут находиться в каталоге Documents , — это сохраненные игры, опять же потому, что это то, что приложение потенциально может предоставить какой-то метод для выбора.

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

Приложения создают файлы и каталоги в каталогах контейнеров iCloud точно так же, как они создают локальные файлы и каталоги. И все атрибуты файла сохраняются, если они добавляют к файлу расширенные атрибуты, эти атрибуты копируются в iCloud, а также на другие устройства пользователя.

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

Как система определяет тип содержимого в файле

Существует два основных метода определения типа содержимого в файле:

Идентификатор унифицированного типа — это строка, которая однозначно идентифицирует класс объектов, которые считаются иметь «тип». UTI предоставляют согласованные идентификаторы для данных, которые все приложения и службы могут распознать и на которые могут полагаться.Они также более гибкие, чем большинство других методов, потому что вы можете использовать их для представления любого типа данных, а не только файлов и каталогов. Примеры UTI включают:

public.text — открытый тип, который идентифицирует текстовые данные.
public.jpeg — общедоступный тип, определяющий данные изображения JPEG.
com.apple.bundle — тип Apple, который определяет каталог пакета.
ком.apple.application-bundle — тип Apple, определяющий связанное приложение.

Если для указания типов файлов доступен интерфейс на основе UTI, вам следует предпочесть этот интерфейс любым другим. Многие интерфейсы macOS позволяют указывать UTI, соответствующие файлам или каталогам, с которыми вы хотите работать. Например, на панели «Открыть» вы можете использовать UTI в качестве фильтров файлов и ограничить типы файлов, выбираемых пользователем, теми, которые может обрабатывать ваше приложение. Несколько классов AppKit, включая NSDocument , NSPasteboard и NSImage , поддерживают UTI.В iOS UTI используются только для указания типов монтажного стола.

Один из способов, которым система определяет UTI для данного файла, — это просмотр его расширения имени файла. Расширение имени файла представляет собой строку символов, добавленную в конец файла и отделенную от основного имени файла точкой. Каждая уникальная строка символов идентифицирует файл определенного типа. Например, расширение .strings идентифицирует файл ресурсов с локализуемыми строковыми данными, а расширение .png определяет файл с данными изображения в формате переносимой сетевой графики.

Примечание: Поскольку символы точки являются допустимыми символами в именах файлов macOS и iOS, только символы после последней точки в имени файла считаются частью расширения имени файла. Все, что находится слева от последней точки, считается частью самого имени файла.

Если ваше приложение определяет пользовательские форматы файлов, вы должны зарегистрировать эти форматы и любые связанные расширения файлов в Info вашего приложения.plist файл. Ключ CFBundleDocumentTypes определяет форматы файлов, которые ваше приложение распознает и может открывать. Записи для любых настраиваемых форматов файлов должны включать как расширение имени файла, так и UTI, соответствующий содержимому файла. Система использует эту информацию для направления файлов соответствующего типа в ваше приложение.

Для получения дополнительной информации об UTI и их использовании см. Uniform Type Identifiers Overview . Дополнительные сведения о ключе CFBundleDocumentTypes см. В разделе Справка по ключу списка свойств информации .

Безопасность: защита файлов, которые вы создаете

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

Для получения общей информации о методах безопасного кодирования при работе с файлами см. Руководство по безопасному кодированию .

Песочницы ограничивают распространение повреждений

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

Разработчикам, создающим приложения для macOS 10.7 и более поздних версий, рекомендуется помещать свои приложения в песочницы для повышения безопасности.Разработчикам приложений для iOS не нужно явно помещать свое приложение в песочницу, потому что система делает это за них автоматически во время установки.

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

Полномочия и списки управления доступом регулируют весь доступ к файлам

Доступ к файлам и каталогам регулируется сочетанием списков управления доступом (ACL) и разрешений BSD.Списки управления доступом — это набор детализированных элементов управления, которые точно определяют, что можно, а что нельзя делать с файлом или каталогом и кем. С помощью списков управления доступом вы можете предоставить отдельным пользователям разные уровни доступа к определенному файлу или каталогу. В отличие от этого, разрешения BSD позволяют вам предоставлять доступ только трем классам пользователей: владельцу файла, одной указанной вами группе пользователей и всем пользователям. См. Обзор безопасности для получения дополнительной информации.

Примечание: Для файла на сетевом сервере не делайте никаких предположений о ACL и разрешениях BSD, связанных с файлом.Некоторые сетевые файловые системы предоставляют только обобщенную версию этой информации.

Поскольку приложения iOS всегда запускаются в изолированной программной среде, система назначает определенные списки управления доступом и разрешения для файлов, созданных каждым приложением. Однако приложения macOS могут использовать службы идентификации для управления списками контроля доступа к файлам, к которым у них есть доступ. Для получения информации о том, как использовать службы идентификации (и платформу совместной работы), см. Руководство по программированию служб идентификации .

Файлы могут быть зашифрованы на диске

И macOS, и iOS поддерживают шифрование файлов на диске:

iOS. Приложение iOS может указать файлы, которые оно хочет зашифровать на диске. Когда пользователь разблокирует устройство, содержащее зашифрованные файлы, система создает ключ дешифрования, который позволяет приложению получить доступ к его зашифрованным файлам. Однако, когда пользователь блокирует устройство, ключ дешифрования уничтожается, чтобы предотвратить несанкционированный доступ к файлам.
macOS. Пользователи могут зашифровать содержимое тома с помощью приложения Disk Utility. (Они также могут зашифровать только загрузочный том из системной настройки безопасности и конфиденциальности.) Содержимое зашифрованного диска доступно приложениям только во время работы компьютера. Когда пользователь переводит компьютер в спящий режим или выключает его, ключи дешифрования уничтожаются, чтобы предотвратить несанкционированный доступ к содержимому диска.

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

Дополнительные сведения о работе с зашифрованными файлами в iOS см. В Руководстве по программированию приложений для iOS .

Синхронизация обеспечивает надежность вашего файлового кода

Файловая система — это ресурс, совместно используемый сторонними приложениями и системными приложениями.Поскольку несколько приложений могут получать доступ к файлам и каталогам одновременно, существует возможность для одного приложения внести изменения, которые сделают представление второго приложения о файловой системе устаревшим. Если второе приложение не готово к обработке таких изменений, оно может перейти в неизвестное состояние или даже выйти из строя. В случаях, когда ваше приложение полагается на наличие определенных файлов, вы можете использовать интерфейсы синхронизации, чтобы получать уведомления об изменениях в этих файлах.

Синхронизация файловой системы — это в первую очередь проблема в macOS, где пользователь может управлять файлами непосредственно с помощью Finder или с любым количеством других приложений одновременно.К счастью, macOS предоставляет следующие интерфейсы, помогающие решить проблемы с синхронизацией:

Файлы, параллелизм и безопасность потоков

Поскольку операции, связанные с файлами, включают взаимодействие с жестким диском и поэтому выполняются медленнее по сравнению с большинством других операций, большая часть файловых операций Связанные интерфейсы в iOS и macOS разработаны с учетом параллелизма. Некоторые технологии включают в себя асинхронные операции, а большинство других могут безопасно выполняться из очереди отправки или вторичного потока.В Таблице 1-4 перечислены некоторые из ключевых технологий, обсуждаемых в этом документе, и указаны сведения о том, безопасны ли они для использования из определенных потоков или любого потока. Для получения конкретной информации о возможностях любого интерфейса см. Справочную документацию по этому интерфейсу.

**Таблица 1-4** Потокобезопасность ключевых классов и технологий
Класс / Технология	Примечания
`NSFileManager`	Для большинства задач безопасно использовать объект по умолчанию `NSFileManager` одновременно из нескольких фоновых потоков.Единственное исключение из этого правила — задачи, которые взаимодействуют с делегатом файлового менеджера. При использовании объекта диспетчера файлов с делегатом рекомендуется создать уникальный экземпляр класса `NSFileManager` и использовать делегата с этим экземпляром. Затем вы должны использовать свой уникальный экземпляр из одного потока за раз.
Grand Central Dispatch	Сам GCD можно безопасно использовать из любого потока. Однако вы по-прежнему несете ответственность за написание своих блоков потокобезопасным способом.
`NSFileHandle` , `NSData` , Потоки Какао	Большинство объектов Foundation, которые вы используете для чтения и записи файловых данных, можно использовать из любого отдельного потока, но не должны использоваться из нескольких потоков одновременно.
Панели открытия и сохранения	Поскольку они являются частью вашего пользовательского интерфейса, вы всегда должны представлять и управлять панелями «Открыть» и «Сохранить» из основного потока приложения.
Подпрограммы POSIX	Подпрограммы POSIX для работы с файлами обычно предназначены для безопасной работы из любого потока. Подробности см. На соответствующих страницах руководства.
`NSURL` и `NSString`	Неизменяемые объекты, которые вы используете для указания путей, безопасны для использования из любого потока. Поскольку они неизменяемы, вы также можете обращаться к ним из нескольких потоков одновременно.Конечно, изменяемые версии этих объектов следует использовать одновременно только из одного потока.
`NSEnumerator` и его подклассы	Объекты перечислителя безопасны для использования из любого одного потока, но не должны использоваться из нескольких потоков одновременно.

Даже если вы используете поточно-ориентированный интерфейс для управления файлом, проблемы все равно могут возникать, когда несколько потоков или несколько процессов пытаются воздействовать на один и тот же файл.Хотя существуют меры безопасности, предотвращающие одновременное изменение файла несколькими клиентами, эти меры не всегда гарантируют постоянный эксклюзивный доступ к файлу. (Вы также не должны пытаться запретить другим процессам доступ к общим файлам.) Чтобы ваш код знал об изменениях, внесенных в общие файлы, используйте файловые координаторы для управления доступом к этим файлам. Дополнительные сведения о координаторах файлов см. В разделе «Роль координаторов файлов и докладчиков»

Как организовать файлы и папки

Вы сидите за своим столом и вносите последние штрихи в сегодняшний большой проект, а ding! приходит сообщение от вашего босса: «Сможете ли вы найти тот проект, который мы отказались от проекта три года назад? Думаю, вы с Джоном из UX работали над ним? Мы думаем о том, чтобы вернуть его снова.«

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

Знакомство со структурами папок

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

Или вы можете бросить все в один ящик и надеяться, что вы найдете подходящую пару носков, когда она вам понадобится. И вот как мы обычно обращаемся с нашими файлами: мы сохраняем файлы в случайном порядке в папки «Рабочий стол» и «Документы», а затем тратим время на поиск файлов каждый день.

Структура папок может помочь, так же как ящики и перегородки помогут упорядочить вашу одежду. Структура папок — это способ организации папок на вашем компьютере. По мере добавления папок с течением времени вы можете либо сохранить их на одном уровне — например, папки 1, 2 и 3 на диаграмме ниже — либо вложить их друг в друга для иерархии — например, подпапки 1B и 1B-1 ниже.Вложенные папки обычно упрощают поиск определенных файлов позже, поскольку вам не нужно просматривать все файлы сразу.

Представьте себе картотечный шкаф с тремя ящиками и несколькими папками в каждом — вот как эта структура папок будет выглядеть в реальной жизни. Вот как та же структура папок будет выглядеть на компьютере, если вы просматриваете свои файлы и папки в режиме списка:

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

Что делает хорошую структуру папок?

Лучшая структура папок — это та, которая имитирует ваш стиль работы. Планируете ли вы важные задачи поквартально? Может быть, неплохо было бы создавать новую папку для работы на каждый квартал. Или вы работаете над проектами? Рассмотрите новые папки для каждого проекта.

Просмотр папок и поиск файлов должны быть интуитивно понятными.Если ваш метод организации утомителен, остальной части вашей команды будет сложно следовать его примеру. Для корпоративных проектов выберите то, что хорошо работает для всех в команде, поскольку каждый не может искать файл или папку так же, как вы. Если вы хотите сохранить структуру папок в долгосрочной перспективе, убедитесь, что все понимают (и, надеюсь, любят!) Систему.

Нет серебряной пули в управлении файлами, но есть несколько уловок, которые помогут вашей файловой структуре добиться успеха.Вот несколько советов от эксперта по управлению цифровыми активами Эдварда Смита:

Создайте шаблон: Копируйте и вставляйте его каждый раз, когда вы начинаете новый проект или задачу. Или, что еще лучше: избавьте себя от хлопот ручного воссоздания структуры снова и снова, настроив Zap, который будет делать это за вас.
Думайте об именах папок как о ключевых словах: Имейте в виду, что вы можете искать файлы, используя имена папок; чем конкретнее, тем быстрее вы найдете то, что ищете.
Сохраняйте уникальность папок: Убедитесь, что содержимое ваших папок не совпадает (например, не должно быть двух мест, где вы храните счета для одного и того же проекта).
Сделайте шпаргалку: Ничего страшного, если вы не запомнили все папки. Нет ничего постыдного в том, чтобы сохранить блок-схему для быстрого ознакомления.

4 Эффективные структуры папок для организации файлов

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

После того, как вы определились с папкой верхнего уровня, пора организовать ваши подпапки.Вот несколько стратегий, которые я использовал в прошлом:

1. Подпапки «Рабочая», «окончательная» и «архивная»

Для этого примера предположим, что папки верхнего уровня уже были организованы по годам, а затем по проекту тип. На скриншоте видно, что мы смотрим на 2016 год, и основные проекты — это реклама, сообщения в блогах, электронные письма клиентов и целевые страницы. Это четыре категории, в которые вы поместите свои различные проекты или задачи.

В папке «реклама» у меня перечислены три задачи.Вот где я использую советы Эдварда Смита. Для каждой задачи я использовал имя папки, чтобы описать срок выполнения (ммгг), тип проекта (в данном случае оплата за клик или PPC) и на какой продукт ориентирована задача. Эти имена папок действуют как теги ключевых слов и добавляют дополнительный уровень организации. Если вы отсортируете папки по имени, они будут автоматически отсортированы по сроку выполнения, а затем по типу проекта. Если вы будете искать по названию продукта или типу рекламы, ваши папки должны легко появиться.

Внутри папки «0116 PPC product x» вы найдете все рабочие, окончательные и архивные файлы, связанные с объявлениями с оплатой за клик за январь 2016 года, ориентированными на продукт X.

Вот как должна работать система рабочий / окончательный / архивный:

Рабочий: Все, над чем вы сейчас работаете. В этом примере эта папка может содержать любую копию объявления, дизайн баннеров или информацию о таргетинге для январской кампании PPC, которая еще не завершена. Это также хорошее место для хранения исходных или исходных файлов.
Final: Все готово для общественного потребления. Не помещайте файлы в последнюю папку, пока они не будут полностью одобрены и в них больше не будут вноситься изменения.В этом примере последняя папка будет содержать только объявления, готовые к публикации в прямом эфире.
Архив: Все, что не помещается в вашу рабочую или конечную папку. Поместите здесь свои заметки, мозговые штурмы, исследования и другую разную информацию. Любые фальстарты здесь тоже могут быть упущены, если вы измените направление в середине проекта. Фальстарт в этом случае может быть рекламной концепцией, над которой вы начали работать, но позже полностью отказались от нее. Не загромождайте рабочие папки файлами, которые никогда не будут считаться «окончательными»; вместо этого закиньте их в архив.

Эта структура папок особенно полезна, если вы работаете над проектом, состоящим из нескольких частей. В этом примере вы, скорее всего, создадите сразу несколько объявлений PPC. Эта система также хорошо работает для команд, работающих над проектом, в котором несколько человек работают над одним и тем же результатом. Человек, который пишет и разрабатывает рекламу, в этом случае, скорее всего, также не будет размещать рекламу. В этом случае человек, публикующий объявление, узнает, когда файлы будут готовы к запуску, проверив последнюю папку.Им не нужно будет спрашивать создателя рекламы, готовы они или нет, что сэкономит всем время.

Собирая все вместе, вот как должна выглядеть ваша полная структура:

2. Подпапки «Для проверки» и «из проверки»

Эта стратегия начинается с тех же папок верхнего уровня, что и в примере выше, но вместо этого фокусируется на сохранении всех версий файла без изменений. Например, в папке «Сообщения блога» я сохранил три разных сообщения. Эти сообщения упорядочены по дате публикации (ммгг) и названы по теме сообщения, а не по заголовку сообщения в блоге, поскольку заголовки часто меняются.

В папке «0216 тема a» вступает в игру структура папок «для просмотра / из обзора». Эта структура очень хорошо работает с файлами, которые будут подвергаться многократному редактированию. Я использовал эту структуру папок во время публикации, чтобы отслеживать все этапы редактирования, набора и проверки, которые входят в готовую книгу.

Я отслеживаю каждый черновик сообщения в блоге, сохраняя его в папке «для проверки» или «из рецензии», что означает, что черновик последний раз редактировался мной («для проверки») или моим редактором (« из обзора »).Это помогает устранить путаницу вокруг номера черновика (я редактировал сообщение в блоге три раза, но мой редактор редактировал дважды). Я также назвал каждый файл в этой папке «v1» или «v2» в зависимости от версии.

Вот как работает эта структура:

01 — черновик (на рассмотрение): По умолчанию ваш первый черновик еще никем не просматривался. Над чем бы вы ни работали (сообщение в блоге, проект графического дизайна, документация и т. Д.), Поместите свой первый черновик в эту папку.Назовите свой файл v1 в конце, чтобы любой, кто встретит файл позже, мог сказать, что это первый черновик. Когда будете готовы, отправьте этот черновик тем, кто должен его просмотреть.
02 — первое редактирование (из рецензии): Когда ваши редакторы отправят свой отзыв о черновике, поместите его в эту папку. Сохраните имя файла, но добавьте инициалы редактора в конце. В этом примере я использую свои собственные инициалы: topic-a-blog-text-v1-CNB означает, что CNB отредактировал версию 1 этого черновика.Больше ничего не делайте с файлом; оставьте все как есть, с каждым изменением нетронутым. Благодаря этому у вас всегда будет запись о том, какие правки были запрошены и кем, и вы сможете делать перекрестные ссылки, чтобы убедиться, что каждое изменение было внесено во второй черновик.
03 — второй черновик (для просмотра): Скопируйте и вставьте файл из папки «02 — первое редактирование (из обзора)» в эту папку. Измените имя файла, включив в конец v2, и удалите инициалы. Это станет вашим вторым черновиком.Откройте файл, внесите изменения и отправьте файл на проверку.
04 — второе редактирование (из просмотра): Эта папка работает так же, как папка «02 — первое редактирование (из просмотра)». Поскольку количество проверок и черновиков, которые проходит ваш файл, может варьироваться, повторяйте эту структуру папок столько раз, сколько необходимо.
05 — окончательная версия (отправлена для публикации): По завершении редактирования поместите свой окончательный черновик сюда. Просматривая свои папки позже, это поможет быстро найти окончательную версию файла.
z — архив: Здесь вы можете поместить все файлы, которые не поместились в указанные выше подпапки.

Если вы еще не сохранили более ранние версии файлов, вы можете восстановить последние предыдущие версии файлов в Dropbox, OS X, Windows и других.

3. Папки «Год» или «Клиент»

Если на вашем рабочем столе находятся сотни файлов, все из которых связаны с работой только для нескольких клиентов, создание папок для каждого клиента может быть лучшим выбором.Или, если у вас огромное количество квитанций на деловые расходы, сортировка их по папкам по годам или месяцам может быть простой структурой, которая вам нужна. Больше папок — не всегда лучше! Как бы просто ни было, найдите систему, которая работает для вас, и придерживайтесь ее. Последовательность — вот что поможет вам оставаться организованным в долгосрочной перспективе.

4. Добавление тегов

Вместо или в дополнение к структурам папок попробуйте пометить файлы тегами. Преимущество тегирования заключается в возможности добавления нескольких тегов к файлу, таких как тегирование счета-фактуры для клиента XYZ тегом «счет-фактура» и тегом «клиент XYZ».Затем вы можете просмотреть все счета вместе или все файлы, связанные с «Client XYZ», вместе, в зависимости от вашего запроса.

Академик и исследователь Уильям Ганн отмечает удобство использования тегов в блоге Mendeley: «С тегами вам не нужно заранее выбирать схему организации». Отвечая на такие вопросы, как «Год пройдет под отделом или над отделом?» становятся ненужными, потому что вы можете добавить в файл теги «год» и «отдел» и при этом легко найти его. Например, если вы работаете над отчетом для отдела логистики, который охватывает все заказы, сделанные в мае 2015 года.Вы можете сохранить отчет в такой структуре папок:

Или вы можете просто добавить в файл теги «отдел», «тип отчета» и «дата» и вообще избегать папок, например:

Итак, когда вы хотите чтобы снова найти этот файл, вы можете выполнить поиск по тегам:

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

Теги работают с любым файлом на Mac под управлением OS X Mavericks или новее.На ПК с Windows теги поддерживаются для некоторых типов файлов и могут быть добавлены в список, разделенный запятыми, через панель свойств файла. Ознакомьтесь с этим руководством для получения дополнительной информации о тегах в Windows.

Автоматически создавать структуры папок для новых проектов

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

Не знаете, когда автоматизировать задачу?

Если вы синхронизируете файлы с OneDrive, Dropbox, Box или Google Диском, вы можете использовать Zapier для автоматического создания структуры папок. Первым шагом к использованию Zapier в этом случае является выбор , когда вам понадобится создать новые папки. Если вы делаете их каждый раз, когда начинаются новые проекты, настройте Zap, чтобы следить за своим приложением управления проектами для нового проекта. Или, если вы хотите, чтобы новые папки создавались каждый месяц или неделю, используйте инструмент Zapier Schedule для создания папок на определенную дату.

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

Например, если клиенты подписываются на вашу службу с помощью формы Wufoo, Zapier добавит их данные в Pipedrive CRM, а затем создаст новую папку проекта в Box вместе с любыми подпапками, которые вы используете в своей структуре папок. Если вам нужно сохранить контракты, шаблоны или другие документы в эту папку, Zapier также скопирует их в эту папку.

Или, если вы хотите создавать новые ежемесячные папки в Dropbox. Запустите Zap с помощью приложения Schedule, выбрав день и время для его запуска. Затем настройте структуру папок, необходимую для работы в течение месяца.

Вот еще несколько записок, которые помогут вам начать работу. Затем вы можете добавить дополнительные шаги в Zap для каждой дополнительной папки, которая нужна вашей структуре.

Как создавать отличные имена файлов

Организация структуры папок — это только половина дела. Чтобы упорядочить ваш компьютер, также потребуется привести в порядок имена файлов.

Файлы состоят из двух компонентов: имени (как бы вы его ни называли) и расширения файла (типа файла, например, .mp3 или .docx ). Обычно вам не нужно беспокоиться о расширениях файлов; они устанавливаются программами, которые вы используете, и обычно скрыты по умолчанию на большинстве компьютеров. Но вы должны взять под свой контроль имя файла. Лучшее имя файла — это такое, которое объясняет, что в файле, без необходимости открывать его.

По этой причине писатель и редактор Джилл Даффи рекомендует убедиться, что имя каждого файла:

Уникальный: Невозможно определить, что находится в файле, если у вас много файлов с одинаковыми именами.
Показательно, что содержится в файле: Является ли ваш файл годовым отчетом? Исследовать? Список дел? Поместите эту информацию в имя файла. Подумайте, какой будет первая реакция получателей, если вы отправите им файл по электронной почте; Лучше всего хранить всю идентифицирующую информацию прямо в имени файла, чтобы любой, кто получает файл, понимал, что в нем содержится.
В соответствии со структурой вашего бизнеса: Это соответствует структуре ваших папок.Ваш бизнес думает о задачах в зависимости от того, для какого клиента они предназначены или в каком месяце что-то нужно сделать?
Возможность сканирования: Убедитесь, что любой, кто быстро взглянет на файл, понимает его имя. Не используйте сокращения, которые не являются общеизвестными, или длинные потоки букв и цифр без каких-либо границ между ними. Включение пробелов не всегда работает, но вы можете использовать подчеркивание, дефис или верблюжий регистр, чтобы имена файлов были удобнее для глаз. Вот пример:

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

Даты: Всегда указывайте даты в формате ггггммдд или yymmdd , поэтому ваши файлы, естественно, будут располагаться в хронологическом порядке.Это правило полезно, но не быстро и сложно. В приведенных выше примерах я использовал mmyy, потому что папки уже были организованы по годам, поэтому самым важным дескриптором стал месяц.
Длина: Имейте в виду, что некоторые программы имеют ограничения на количество символов в именах файлов. & * () `; <>? , [] {} ‘»|.
Последовательные файлы: Если вы называете файлы, которые идут по порядку, используйте ведущие нули (01, 02, 03 вместо 1, 2, 3). Это гарантирует, что ваши файлы (или папки) будут выстроены так, как вы хотите.

Учтите, что использовать все эти правила необязательно. В библиотеках Purdue University есть несколько советов, которые помогут вам максимально эффективно использовать любое соглашение об именах файлов, которое вы в конечном итоге выберете:

Найдите баланс: Только вы можете решить, что слишком много или слишком мало в имени.
Задокументируйте свою систему: Создайте шпаргалку из любых сокращений, которые вы часто будете использовать, или правил, которые вы можете забыть.
Начните с общего, затем переходите к конкретному: Поскольку ваши имена файлов будут естественным образом отсортированы из того, что вы вводите первым, начните с наиболее общих компонентов (год, отдел, клиент и т. ID, версия и т. Д.). Общее эмпирическое правило: все, что вы хотите увидеть в первую очередь, сначала пишите.

Как быстро найти файлы

Spotlight в OS X может находить файлы, электронные письма, поиск в Интернете и многое другое.

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

На Mac Spotlight позволяет искать в файлах и сообщениях электронной почты и просматривать их, чтобы убедиться, что вы нашли то, что ищете.Нажмите кнопку поиска в строке меню (или нажмите CMD + пробел), затем введите имя файла или папки, которые вы ищете. На iPad или iPhone просто потяните вниз главный экран для упрощенного поиска Spotlight, чтобы просматривать электронные письма, заметки и приложения на ходу, или воспользуйтесь инструментом поиска в приложении Dropbox или Google Диск на любом телефоне, чтобы найти синхронизированные файлы.

На ПК под управлением Windows Vista, 7 или 8.1 в меню «Пуск» есть поле поиска для поиска файлов и папок. В Windows 10 рядом с кнопкой «Пуск» есть кнопка поиска Cortana, с помощью которой можно искать файлы и папки, а также узнавать погоду или искать в Интернете.

Если вы хотите, чтобы дополнительные инструменты могли глубже копаться в папках или автоматически запускать определенные программы, есть также сторонние поисковые приложения. Alfred — это популярный и мощный инструмент поиска для Mac, а Launchy — обычный инструмент для поиска в Windows.

Zapier может искать файлы и папки в Box автоматически.

Вы также можете искать файлы внутри самих приложений. Dropbox, Google Drive и Box позволяют выполнять поиск по синхронизированным файлам и папкам, а Zapier может выполнять поиск во многих ваших приложениях для повышения производительности.Zaps может искать определенные файлы и папки в Box — возможно, чтобы найти папку клиента — а затем сохранять файлы из других приложений в эту папку, чтобы все было организовано автоматически.

Организуйте свои файлы сегодня

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

Рассмотрите возможность архивации всех старых файлов, переместив их в папку «Старые файлы» или «Архив». Бросьте все, что вам больше не нужно. Когда у вас будет время, вы можете пройти через эту папку «Архив» и хранить файлы, используя ту же структуру папок, которую вы уже начали использовать для новых файлов.

Какую структуру папок вы используете для упорядочивания файлов? Мы будем рады услышать об этом в комментариях ниже!

Используете Dropbox для организации файлов? Ознакомьтесь с этими 12 скрытыми функциями Dropbox, чтобы узнать о других способах организации и быстрого поиска файлов, когда они вам понадобятся.

Что такое файловое хранилище и чем оно отличается от объектного хранилища

В чем разница и почему это имеет значение

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

Все мы знаем, что объем данных стремительно растет — организациям приходится покупать больше хранилищ данных, чем когда-либо прежде. И это большая проблема. Однако каждая организация сталкивается с другой большой проблемой, которая затрагивает всех — руководителей бизнеса, ИТ-специалистов и пользователей, — хотя и влияет на них по-разному. И вот что: не все данные одинаково ценны.

Данные похожи на наличные деньги. Мы обрабатываем, защищаем и используем наличные деньги в нашем кошельке по-разному в зависимости от их стоимости. Мы гораздо внимательнее относимся к тому, как мы заботимся о 100-долларовых счетах и как тратим их, чем о 1-долларовых счетах.То же самое и с данными. Не все из них одинаково важны и, что более важно, его ценность со временем меняется — обычно из-за содержащейся в нем информации, частоты доступа и даже возраста данных. В идеале организации должны иметь платформы хранения, которые созданы для разумной обработки важности данных, а не просто для неразумного хранения битов и байтов. Вот почему поставщики хранилищ данных ввели понятие «температура данных».

Для иллюстрации: обычно наблюдается короткий всплеск неистовой активности с вновь созданными данными, но со временем эта активность быстро спадает.Обычно 90% операций ввода-вывода приходится на 10% хранилища данных. Для большинства организаций также верно то, что активно используется только около 20% всех данных. Таким образом, 80% данных просто пугают. Его можно использовать раз в месяц, раз в год или никогда больше. На изображении ниже показано, как температура данных соотносится со своим значением. Горячие данные активно используются и очень ценны для организации. Неактивные данные холодны и менее ценны, но вам все равно придется хранить их для возможного использования в будущем, что может снова сделать их горячими.

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

Давайте посмотрим на мир неструктурированных данных, в котором данные более распределены, и на два популярных формата хранения данных: файловую систему и хранилище объектов.

Что такое файловое хранилище?

Файловое хранилище (также известное как файловое хранилище или хранилище на уровне файлов) — это тип хранилища данных, в котором данные хранятся в иерархической структуре файлов и папок.Файл хранится как единое целое без разделения данных на блоки, например в блочном хранилище. Файлы могут храниться в папках, которые затем могут быть помещены в другие папки во вложенной структуре. Путь к каталогу файла и папка, в которой он хранится, необходимы для повторного вызова этого файла из места его хранения. В системах NAS обычно используется файловое хранилище, и они сравнительно дешевле, чем блочные хранилища.

Что такое файловая система хранения

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

Для хранения файлов, выходящих за рамки обычного настольного компьютера или ноутбука, организации используют решения NAS (Network Attached Storage) и файловые серверы, чтобы обеспечить специализированные и оптимизированные возможности совместного использования файлов в сети. Обычно они обеспечивают поддержку протоколов NFS и SMB для использования в средах Unix, Linux и Windows. Они отлично подходят для хранения или совместного использования файлов и документов.

NAS

обычно подходит для хранения или совместного использования файлов и документов, а также для управления доступом. Но, как вы знаете по собственному рабочему столу, вы работаете только с несколькими файлами за раз.Большинство файлов на жестком диске холодные или холодные. Если это верно для файлового сервера или NAS, системе не хватает памяти или падает производительность — как и у вашего ноутбука. В таких случаях ИТ-организации могут рассматривать хранилище объектов как средство хранения холодных (или неактивных) данных.

Что такое объектное хранилище?

Объектное хранилище (также известное как объектное хранилище) — это тип хранилища данных, используемый для обработки больших объемов неструктурированных данных, где данные объединяются вместе с тегами метаданных и уникальным идентификатором.Каждый из этих автономных наборов объектных данных помещается в плоское адресное пространство, известное как пул хранения. В отличие от файлового хранилища, объектное хранилище не имеет иерархической структуры. Метаданные содержат описание данных, а уникальный идентификатор используется для легкого извлечения объекта вместо имени файла и пути к файлу. Облачное хранилище S3 — это популярный вариант хранилища объектов в дополнение к развертыванию локального хранилища объектов.

Понимание системы хранения объектов

Объектное хранилище — это более свежий подход, который не навязывает файловую систему данным.Вместо этого используются метаданные для описания всех деталей о базовых данных. Это может включать имя, дату создания, местоположение, владельца и многое другое. Таблицы используются для того, чтобы можно было хранить, отслеживать и извлекать данные на основе этих метаданных.

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

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

Помещение нужных данных в нужное место в нужное время

Главный вывод: разные данные имеют большую или меньшую ценность в зависимости от времени, пользователей и важности. Это означает, что наиболее подходящее хранилище для любых конкретных данных будет зависеть от того, насколько они ценны в данный момент и от конкретных потребностей приложений или конечных пользователей, использующих их, или от его важности для бизнеса. И администратору хранилища практически невозможно определить это изо дня в день. В конце концов, ваша организация создает миллионы документов каждый год.Можете ли вы представить себе, как администратор хранилища копается в каждом документе, пытаясь решить, является ли он горячим, теплым или холодным, или вручную применяет различные условия релевантности для бизнеса и решает, какие данные размещать на каком устройстве хранения?

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

Вот здесь и появляется современное программно-определяемое решение для хранения данных, такое как vFilO от DataCore.

Он использует автоматическое размещение на основе AI / ML для перемещения данных в наиболее подходящее хранилище в зависимости от температуры доступа. vFilO проверяет тепловой шаблон данных, хранящихся на устройстве хранения, а затем определяет, следует ли хранить данные на устройстве NAS премиум-класса или переместить их в более дешевые альтернативы (например, хранилища объектов). vFilO проверяет не только частоту доступа к данным, но и другие настраиваемые критерии, основанные на важности бизнеса, которые может установить администратор хранилища, например возраст файла, местоположение, отказоустойчивость и т. д.Это означает, что вы можете сбалансировать производительность, емкость, операционную эффективность и факторы стоимости. Высокопроизводительное и дорогое хранилище может быть зарезервировано для горячих данных, в то время как критически важные (или неактивные) данные могут быть перенесены в дешевое хранилище или облако.
Вы можете задействовать все доступные ресурсы в организации, открывая карманы неиспользуемого хранилища, о котором вы даже не подозревали. Это означает, что вы можете отложить дорогостоящие обновления или вообще их избежать.
Благодаря глобальному пространству имен легко найти нужные данные, когда они вам понадобятся.Все данные файлов и объектов теперь доступны с центральной консоли, независимо от того, на каком устройстве / типе хранилища они находятся. Используя поиск и поиск на основе метаданных, vFilO ускоряет процесс поиска и доступа к данным на различных типах устройств хранения (файловых или объект, хранящийся локально или в облаке).

Почему эти факторы так важны для руководителей бизнеса, ИТ-администраторов и пользователей прямо сейчас?

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

В качестве альтернативы, почему бы не позвонить в DataCore, чтобы обсудить ваши конкретные требования?

Полезные ресурсы:

[MS-FSCC]: Глоссарий | Документы Microsoft

28.05.2021
Читать 12 минут

В этой статье

В этом документе используются следующие термины:

8.3 name : Имя файла строка ограничена длиной до 12 символов, которая включает базовое имя до восемь символов, один символ для точки и до трех символов для расширение имени файла. Дополнительные сведения об именах файлов формата 8.3 см. В [MS-CIFS]. раздел 2.2.1.1.1.

список управления доступом (ACL) : Список записей управления доступом (ACE), которые в совокупности описывают безопасность правила авторизации доступа к какому-либо ресурсу; например, объект или набор объекты.

альтернативное имя : Имя в формате 8.3, которое может необязательно генерируется при создании файла. У файла не будет альтернативного имени, если пользователь хочет оптимизировать производительность, или если имя файла уже использует 8.3 формат.

большой двоичный объект (BLOB) : Коллекция двоичных данных, хранящихся как единый объект в базе данных.

фрагмент : объем данных что реализация операционной системой сжатия Lempel-Ziv алгоритм пытается сжать за один раз.Размер используемого блока сжатия файловой системой всегда кратно базовому сжатию размер блока алгоритма. Для получения дополнительной информации о компрессии Lempel-Ziv алгоритм, см. [UASDC].

кластер : самый маленький единицы размещения на томе.

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

сдвиг блока сжатия : Количество битов, на которое нужно сдвинуть влево на 1 бит, чтобы получить размер блока сжатия.

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

дисковая квота : максимум количество данных, которые пользователь может хранить на дисковом томе.

Отслеживание распределенных ссылок (DLT) : протокол, позволяющий клиентским приложениям отслеживать источники, были отправлены в удаленные места с использованием удаленного вызова процедур (RPC) интерфейсы и поддерживать ссылки на файлы.Он предоставляет методы, принадлежащие два интерфейса, один из которых существует на сервере (trksvr), а другой — на рабочая станция (trkwks).

имя каталога точек : в путь, компонент имени каталога «.» или же «..». Для подробнее см. раздел 2.1.5.1.

Файловая система FAT : файл система, используемая для организации файлов и управления ими. Таблица размещения файлов (FAT) это структура данных, которую создает операционная система при форматировании тома с помощью с использованием файла FAT или FAT32 системы.Операционная система хранит информацию о каждом файле в FAT, чтобы она могла извлекать файл позже.

Fid : 16-битное значение, которое сервер блока сообщений сервера (SMB) использует для представления открытого файла с именем труба, принтер или устройство. Fid возвращается SMB сервер в ответ на запрос клиента открыть или создать файл, именованный канал, принтер или устройство. Сервер SMB гарантирует, что возвращаемое значение Fid равно уникален для данного SMB-соединения до тех пор, пока SMB-соединение не будет закрыто, при этом время, когда значение Fid может можно использовать повторно.ФИД используется клиентом SMB в последующих командах SMB для идентификации открытого файла, именованный канал, принтер или устройство.

таблица размещения файлов (FAT) : Структура данных, создаваемая операционной системой при форматировании тома. с использованием FAT или FAT32 файловые системы. Операционная система хранит информацию о каждом файле в FAT, чтобы она могла извлекать файл позже.

компонент имени файла : часть имени файла между символами разделителя пути (или обратной косой чертой).

сегмент записи файла : A запись в мастере таблица файлов, содержащая атрибуты для конкретного файла на томе NTFS. Запись файла сегмент всегда имеет размер 1024 байта (1 килобайт).

файловый поток : См. Главную поток и именованный поток.

Управление файловой системой (FSCTL) : Команда, отправляемая файловой системе для изменения или запроса поведения файла. система и / или набор или запрос метаданных, связанных с конкретным файлом или с самой файловой системой.

фильтр : Тип драйвера который расположен между ядром и базовой файловой системой (например, FAT или NTFS), которая получает ввод-вывод запрашивать пакеты на пути к базовой файловой системе и обратно. Термин «фильтр» может относиться к устаревшей версии. фильтры или минифильтры.

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

глобальный уникальный идентификатор (GUID) : термин, используемый как синоним универсального уникального идентификатора. (UUID) в технических документах протокола Microsoft (TD). Изменение использования этих условий не подразумевает и не требует определенного алгоритма или механизма для генерировать ценность. В частности, использование этого термина не подразумевает или требовать, чтобы использовались алгоритмы, описанные в [RFC4122] или [C706] для генерации GUID.См. Также универсальный уникальный идентификатор (UUID).

GUIDString : GUID в форме Строка ASCII или Unicode, состоящая из одной группы из 8 шестнадцатеричных цифр, за которыми следуют три группы по 4 шестнадцатеричных цифры в каждой, за которыми следует одна группа 12 шестнадцатеричных цифр. Это стандартное представление GUID, как описано в разделе 3 [RFC4122]. Например, «6B29FC40-CA47-1067-B31D-00DD010662DA». В отличие от строки GUID в фигурных скобках, строка GUIDString не заключена в фигурные скобки.

Управление вводом / выводом (IOCTL) : A команда, которая отправляется целевой файловой системе или целевому устройству, чтобы запросить или изменить поведение цели; или запросить или изменить данные и атрибуты, связанные с целью или открытыми объектами по цели.

независимый поставщик программного обеспечения (ISV) : компания или организация, разрабатывающая программные решения, которые могут используйте эту спецификацию.

логический номер кластера (LCN) : Номер кластера относительно начала тома. Первый кластер по объему равен нулю (0).

основная файловая таблица (MFT) : На томе NTFS MFT — это реляционная база данных, состоящая из строк файловых записей и столбцов файла атрибуты. Он содержит как минимум одну запись для каждого файла на томе NTFS, включая MFT. сам.MFT хранит информацию, необходимую для извлечения файлов из раздела NTFS.

зеркало таблицы мастер-файлов (MFT2 / MFTMirr) : в NTFS громкости, MFT2 — это дублирующая копия первых четырех (4) записей MFT.

именованный поток : место внутри файла в дополнение к основному потоку, в котором хранятся данные, или данные хранится в нем. Файловые системы поддерживают режим, в котором можно открывать либо основной поток файла, и / или открыть именованный поток.Именованные потоки имеют данные, отличные от данных основного потока (и друг друга), и могут быть прочитаны и написано самостоятельно. Не все файловые системы поддерживают именованные потоки. Смотрите также Основной поток.

Имя NetBIOS : 16-байтовый адрес, который используется для идентификации ресурса NetBIOS в сети. Для большего информацию см. [RFC1001] и [RFC1002].

Файловая система NT (NTFS) : A собственная файловая система Microsoft. Для получения дополнительной информации см. [MSFT-NTFS].

ID объекта : см. ObjectID.

идентификатор объекта (OID) : В контексте объектного сервера — 64-битное число, однозначно идентифицирующее объект.

объектно-ориентированная файловая система : В контексте управляющих кодов файловой системы файловая система, которая позволяет присвоение файлов идентификаторов объектов.

Чтение разгрузки : вариант к нормальной операции чтения, когда целевое устройство генерирует и возвращает токен вместо буфера содержащие данные для чтения. Токен поддерживается целевое устройство, пока оно не аннулирует токен для любого причина, зависящая от поставщика.Данные, логически представленные токеном, не могут измениться, и целевое устройство требуется для поддержания этого представления. Пример целевое устройство — это массив хранения SAN с поддержкой связанного низкоуровневого команды хранения. Для получения дополнительной информации о чтении разгрузки см. [INCITS-T10 / 11-059].

Запись разгрузки : вариант A к нормальной операции записи, когда хост предоставляет токен вместо буфера содержащие данные для записи. После получения Offload Write цель устройство анализирует токен и определяет, может ли быть завершено перемещение данных (Запись) в запрошенное место.Примером целевого устройства является массив хранения SAN с поддержка связанных низкоуровневых команд хранения. Для получения дополнительной информации о разгрузочной записи см. [INCITS-T10 / 11-059].

точка повторной обработки : An атрибут, который можно добавить в файл для хранения набора определяемых пользователем данные, непрозрачные для NTFS или ReFS. Если открыт файл с точкой повторной обработки, обычно открывается сбой с STATUS_REPARSE, так что соответствующий драйвер фильтра файловой системы может обнаружить открытие файла, связанного с этой точкой повторной обработки (принадлежащего ей).При этом точка, каждый установленный фильтр драйвер может проверить, является ли он владельцем точки повторной обработки, и, если да, выполнить любую специальную обработку, необходимую для файла с этой точкой повторной обработки. В формат этих данных понимает приложение, которое хранит данные и фильтр файловой системы который интерпретирует данные и обрабатывает файл. Например, фильтр шифрования, помеченный как владелец точки повторной обработки файла может найти ключ шифрования для этого файл. С файлом может быть связана (не более) 1 точка повторной обработки.Для большего информацию см. [MS-FSCC].

Тег точки повторной обработки : A уникальный идентификатор драйвера фильтра файловой системы, хранящийся в необязательный повторный анализ файла точечные данные, указывающие драйвер фильтра файловой системы, который выполняет дополнительная обработка файла, определяемая фильтром, во время операций ввода-вывода. An разработчик может запросить более одной точки повторной обработки для использования с файловая система, фильтр файловой системы драйвер или драйвер минифильтра. Чтобы запросить тег точки повторной обработки, используйте команду reparse форма запроса тега точки.Для получения дополнительной информации см. [WHDC-RPTR].

набор реплик : в файле Служба репликации (FRS), репликация файлов и каталогов согласно в заранее заданную топологию и расписание для конкретной папки. Топология и расписание вместе называются набором реплик. Набор реплик содержит набор реплики, по одной для каждой машины, участвующей в репликации.

сектор : самый маленький адресный блок диска.

идентификатор безопасности (SID) : Идентификатор участников безопасности, который используется для идентификации учетной записи или группа.Концептуально SID состоит из части полномочий учетной записи (обычно домена) и меньшего целое число, представляющее личность, относящуюся к полномочиям учетной записи, называемое относительный идентификатор (RID). Формат SID указан в [MS-DTYP] раздел 2.4.2; строковое представление идентификаторов безопасности указано в [MS-DTYP] раздел 2.4.2 и [MS-AZOD] раздел 1.1.1.2.

короткое имя : Это то же определение, что и альтернативный название.

одноэкземплярное хранилище (SIS) : Функция NTFS, которая реализует связи с семантикой копий для файлов, хранящихся на томе NTFS.SIS использует копирование близко к реализовать семантику копирования своих ссылок.

разреженный файл : файл содержащие большие участки данных, состоящие только из нулей. Этот файл отмечен как разреженный файл в файловой системе, что экономит место на диске, выделяя только столько диапазонов на диске, сколько требуется для полного восстановления ненулевого данные. Когда делается попытка прочитать нераспределенные части файла (также известные как дыры), файловая система автоматически возвращает нули в звонящий.

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

дополнительное чтение и дополнительная запись : Операция ввода-вывода, отправляемая файловой системой в стек хранения, который является частью операция ввода-вывода больших файлов. Иногда чтение и запись больших файлов прерываются файловой системой на более мелкие операции чтения и записи, которые затем отправляются в стек хранения.

символическая ссылка : символическая ссылка — это точка повторной обработки, которая указывает в другой объект файловой системы. Указанный объект называется цель. Символические ссылки прозрачны для пользователей; ссылки отображаются как обычные файлы или каталоги, и точно так же может действовать пользователь или приложение.Символические ссылки могут быть создается с использованием запроса FSCTL_SET_REPARSE_POINT, как указано в [MS-FSCC] раздел 2.3.61. Их можно удалить с помощью FSCTL_DELETE_REPARSE_POINT запрос, как указано в разделе 2.3.5 [MS-FSCC]. Реализация символических ссылок не является обязательной. для файловой системы.

tag : Другое имя точки повторной обработки. Для например, фильтр файловой системы Подпрограмма менеджера FltTagFile устанавливает точку повторной обработки файла. Тег также используется для ссылки на поле в точке повторной обработки, которая определяет, какой программный компонент поставил точку повторной обработки.

токен : длина 512 байт непрозрачная строка, которая создается и поддерживается поддерживаемым целевым устройством. Токен функционирует логически как неизменное представление на определенный момент времени для набора данных, заданных хост и может быть концептуализирован как сжатое представление данных, которые интерпретировать может только определенный класс подсистем хранения. Токен также может быть построенный из набора хорошо известных токенов, чтобы позволить клиенту для описания однородного атрибута для набора данных (например, все нули) или позволить серверу применять однородный атрибут к набору данных (для Например, набор всех нулей).Для получения дополнительной информации о токенах см. [INCITS-T10 / 11-059].

Символ Unicode : Если только в противном случае — 16-битная кодовая единица UTF-16.

Единый указатель ресурсов (URL) : строка символов в стандартизированном формате, определяющая документ или ресурс в Интернете. Формат указан в [RFC1738].

Универсальный дисковый формат (UDF) : Тип файловой системы для хранения файлов на оптических носителях.

номер последовательности обновления (USN) : Смещение от начала потока журнала изменений, которое однозначно идентифицирует запись журнала изменений.

номер виртуального кластера (VCN) : Номер кластера относительно начала файла, каталога или потока в файле. Кластер, описывающий байт 0 в файле стоит VCN 0.

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

МАЙ, ДОЛЖЕН, ДОЛЖЕН, НЕ ДОЛЖЕН, НЕ ДОЛЖЕН: Эти термины (все заглавными буквами) используются как определено в [RFC2119]. Все Заявления о необязательном поведении могут использовать МОЖЕТ, ДОЛЖЕН или НЕ ДОЛЖЕН.

Новое поколение технологий файловых систем

Журнал D-Lib

Февраль 1998 г.

ISSN 1082-9873

Электронные библиотеки

Новое поколение технологий файловых систем

Мик Боуман и Билл Камарго
Transarc Corporation
Питтсбург, Пенсильвания
mic @ transarc.com и [email protected]

В этой статье исследуется совместное использование файлов в корпорациях, использующих глобальные распределенные файловые системы. Приложения и взаимодействие с пользователем убедительно свидетельствуют о том, что добавление услуг, обычно связанных с электронными библиотеками, улучшит совместную работу. Среди этих услуг — расположение файлов на основе содержимого, строго типизированные объекты, представление сложных отношений между документами и внешние метаданные.Когда эти службы добавляются к глобальным файловым системам, интеграция приложений значительно улучшается.

1.0 Введение

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

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

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

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

Остальная часть этого документа представлена следующим образом: Раздел 2 описывает характеристики и преимущества глобальной файловой системы. В разделе 3 перечислены три приложения для совместной работы, которые типичны для глобальных файловых систем.В разделе 4 перечислены несколько проблем, которые влияют на совместную работу на основе файловой системы. Раздел 5 предлагает несколько новых сервисов файловой системы, взятых из технологии цифровых библиотек, которые добавляют недостающие операции управления информацией. В разделе 6 суммируются усилия в этой области. Раздел 7 завершается.

Преимущества глобальной файловой системы

2.0

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

AFS, файловая система Andrew, служит примером возможностей, обычно доступных в глобальной файловой системе [Howard88, Spector89]. Используя набор доверенных серверов, AFS предоставляет клиентам прозрачное по местоположению иерархическое пространство имен. Это означает, что пользователь работает с общей структурой каталогов, обращаясь к файлам со своей рабочей станции Unix в Питтсбурге или с персонального компьютера в своем вспомогательном офисе в Токио.

Том AFS состоит из набора файлов и каталогов, расположенных на одном сервере, и образует частичное поддерево общего пространства имен [Sidebotham86].Распределение томов по серверам — это административное решение. Чтобы сбалансировать нагрузку между набором серверов, администратор может переносить занятые тома с одного сервера на другой. Тома, которые часто читаются, но редко изменяются (например, системные двоичные файлы), могут иметь реплики только для чтения на нескольких серверах для повышения доступности и распределения нагрузки на сервер. Поскольку имя файла не зависит от сервера, на котором он хранится, миграция и репликация тома улучшают доступность и снижают нагрузку на сервер без изменения представления пользователя о файловой системе.

Рисунок 1. Пример глобального пространства имен, совместно используемого пользователями AFS.

AFS использует агрессивную политику кэширования файлов для уменьшения сетевой нагрузки и задержки доступа [Kazar88]. Когда пользователь обращается к файлу, глобальная файловая система сначала проверяет кеш локального диска на наличие копии файла. При обычном доступе к файлам у пользователя есть «рабочий набор» файлов, который остается неизменным в течение определенного периода времени. В результате в среднем 98% запросов на данные файла и 96% запросов на статус файла не требуют доступа к серверу [Spasojevic96].

Безопасность в глобальной файловой системе основана на механизме аутентификации и безопасном RPC между серверами и клиентами. Хотя все участвующие сайты должны согласовать общую модель защиты и авторизации, каждый сайт имеет полный контроль над реализацией индивидуальных политик безопасности. AFS использует списки контроля доступа для защиты. Список контроля доступа — это набор пар; первый элемент в каждой паре — это имя пользователя или группы, а второй — это информация о правах, предоставленных этому пользователю или группе.Пользователи могут создавать новые группы, а также указывать отрицательные права. Эта модель авторизации позволяет точно указать права управления доступом для каждого пользователя и каждой части глобальной файловой системы. По соображениям производительности степень детализации защиты — это весь каталог, а не отдельные файлы.

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

3.0 Характеристики использования

Организации, которые развертывают продукты для глобальных файловых систем, используют их для различных целей.В этом разделе описываются общие действия по совместному использованию файлов среди пользователей технологии глобальной файловой системы. Эти примеры демонстрируют три вида сотрудничества, которые облегчает технология глобальной файловой системы: совместное администрирование, целенаправленное сотрудничество и распространение совместно используемой информации.

3.1 Управление конфигурациями программного обеспечения

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

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

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

Хотя общий репозиторий программного обеспечения упрощает задачу развертывания конфигураций программного обеспечения, он не помогает администраторам решать, что должно содержаться в репозитории.Зависимости между пакетами — например, приложениями, которым для правильной работы требуется определенная версия операционной системы, — усложняют процесс принятия решения о том, какое программное обеспечение можно удалить из архива. После принятия решения об удалении пакета администратор должен идентифицировать различные части пакета. Это осложняется обычным подходом к установке, когда файлы помещаются в несколько разных каталогов; то есть двоичные файлы в одном, библиотеки в другом и документация в третьем.Сторонние утилиты установки решают некоторые из этих проблем с помощью специального средства «Удалить».

3.2 Разработка программного обеспечения

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

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

Чтобы понять сложность взаимодействия в этой среде, рассмотрите действия, которые происходят, когда клиент сообщает о проблеме с продуктом, как показано на рисунке 2.Сначала специалист службы поддержки, который обрабатывает вызов, создает отчет о дефектах и начинает поиск схожих проблем в документации по продукту, примечаниях к выпуску и других отчетах о дефектах. Поскольку многие хранилища информации, доступные специалисту службы поддержки, не предназначены для поиска решений для программных дефектов, поиск соответствующих документов является сложным и трудоемким процессом. Если нет документов, описывающих решения проблемы, специалист службы поддержки может отправить запрос на доску объявлений с просьбой о помощи.В крайнем случае, дефект передается на расследование в организацию-разработчик.

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

Чтобы исправить дефект, разработчик изучает отчет о дефекте и все связанные с ним пояснительные материалы, инициирует изменение состояния исходного кода продукта, устраняет проблему и указывает, что новое состояние является стабильным. Поскольку разработчики часто изменяют одни и те же файлы параллельно, необходимо объединить стабильные состояния.Разработчик, ответственный за слияние, проверяет изменения, инициирует изменение состояния, разрешает конфликты и отмечает состояние как стабильное.

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

Участники этого процесса широко используют общую файловую систему. Все соответствующие документы хранятся в виде файлов (включая сообщения на доске объявлений). Разработчики используют личную «песочницу» для изменения файлов, чтобы изолировать стабильные версии исходного кода. Системное тестирование и разработка продукта получают ссылки на стабильные конфигурации исходного кода.

3.3 Корпоративная информация

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

Электронная почта — один из способов передать эту информацию сотрудникам. Электронная почта как push-технология полезна в качестве агента уведомления. Однако архивирование корпоративной информации в глобальной файловой системе дает несколько преимуществ.Во-первых, хранение одной копии каждого файла в файловой системе более эффективно, чем хранение копии на каждой машине. Во-вторых, администраторы файловой системы следят за регулярным резервным копированием. Однако большинство пользователей не создают резервные копии файлов постоянно. Наконец, средства контроля доступа к файлам гарантируют защиту конфиденциальной информации от несанкционированного доступа. Как и в случае с резервными копиями, администраторы файловой системы могут создавать хранилища файлов, требующих особой защиты, чтобы пользователям не нужно было беспокоиться о написании правильных элементов управления доступом.

Многие организации сейчас используют HTTP-серверы для распространения корпоративной информации [Rein97]. Наличие общедоступной совместно используемой файловой системы упрощает публикацию документов (особенно когда HTTP-сервер настроен для извлечения документов непосредственно из совместно используемой файловой системы) и позволяет переложить часть нагрузки, связанной с доступом к документам, на файловую систему. В частности, запросы файлов могут эффективно обрабатываться файловой системой [Spasojevic94].HTTP-сервер продолжает обрабатывать запросы динамических документов, таких как вывод сценариев CGI и файлы, объединенные с включениями на стороне сервера.

4.0 Проблемы и проблемы

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

4.1 Масштаб

Корпоративные вычисления — это основная область применения глобальных файловых систем. В результате развернутые файловые системы обычно очень большие. Например, 450 сотрудников Transarc имеют доступ к 830 гигабайтам общих файлов из нескольких офисов в США и двух международных офисов.Коллекция файлов в Transarc — одна из 149 коллекций, доступных через публичное пространство имен AFS. В ходе исследований, проведенных три года назад (когда количество участвующих организаций составляло 80), общий объем данных файловой системы, доступных через AFS, составил примерно 5 терабайт [Spasojevic96].

Масштабирование создает множество проблем на уровне системы, например, производительность и надежность, которые решаются базовой технологией. Однако проблемы на уровне пользователя остаются без внимания.В частности, поиск файлов является ключевым ограничением для совместной работы. Манипуляции с пространством имен — размещение файла в определенном каталоге — это единственный метод, который файловая система предоставляет для упрощения местоположения файла. Хотя этот подход хорошо работает для управления небольшими коллекциями, его полезность для организации больших коллекций имеет ограничения.

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

Во-вторых, поскольку файл может быть помещен только в один каталог, его расположение в пространстве имен может представлять только один аспект файла. Это ограничение часто вызывает проблемы, когда коллекции связанных файлов должны быть помещены в отдельные каталоги для размещения существующих иерархий, как в случае установки многих пакетов программного обеспечения.Документация размещается в одном каталоге, двоичные файлы — в другом, общие библиотеки — в третьем, а файлы конфигурации — в четвертом. Это происходит потому, что системные администраторы считают, что наиболее полезная организация требует размещения всех двоичных файлов в одном каталоге. Без дополнительных ресурсов сложно найти все компоненты приложения после его установки.

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

4.2 Внутренняя структура

Традиционный интерфейс файловой системы обрабатывает файлы как нетипизированные байтовые потоки. Однако мы наблюдаем, что большинство файлов имеют идентифицируемую структуру, определяемую форматом и ролью. Формат файла — это грамматика, которая представляет физическое расположение информации в файле. Роль связывает определенный словарный запас с грамматикой. Например, текстовый редактор определяет определенный формат файла, но данный файл может содержать письмо, статью или книгу.

Между файлами есть различия как по формату, так и по ролям. Для календаря существует множество форматов, зависящих от приложения, но общая роль подразумевает фундаментальный набор операций, которые являются общими для всех: список встреч, чтение встречи и запись встречи. Приложения часто специализируются на роли; т.е. добавить операции в интерфейс. Точно так же существует множество различных типов документов — письма, публикации в журналах, книги — которые могут быть представлены одним форматом файла, таким как LaTeX.

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

4.3 Неоднородность

Каждый раз при совместном использовании файлов неоднородность создает проблему сопоставления данных с приложениями.Чтобы избежать множественных преобразований, два человека, которые вместе пишут статью, выбирают общее приложение, которое будет использоваться для форматирования статьи. Глобальные файловые системы позволяют сотням тысяч пользователей из университетов, государственных лабораторий, финансовых учреждений и других коммерческих организаций обмениваться файлами через единое единое пространство имен. Соглашения между пользователями по аппаратному обеспечению, приложениям, форматам и организации невозможны. В результате неоднородность преобладает во многих формах:

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

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

4.4 Неявные отношения

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

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

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

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

Аннотации — то есть файлы, которые объясняют или разъясняют содержимое другого файла — встречаются во многих формах в глобальной файловой системе. В ответном сообщении содержится аннотация к исходному сообщению. Группа сообщений, содержащих взаимодействия между компанией и конкретным клиентом, служит аннотацией для отчета о продажах. В документе, описывающем структуру программного компонента, приводятся дополнительные сведения о серии изменений исходного кода программы.

Как и в случае с традиционными цифровыми библиотеками, файловые системы должны поддерживать альтернативные представления документа.Например, вычисления в масштабе предприятия часто связаны с разнородными аппаратными архитектурами. Чтобы упростить развертывание приложений, системные администраторы предпочитают единое пространство имен для всех архитектур. Файловые системы часто предоставляют зависящие от контекста имена каталогов, чтобы удовлетворить эту потребность. Например, в AFS имя «@sys» заменяется именем аппаратной архитектуры клиентского компьютера. На Sun Sparcstation имя «/afs/transarc.com/@sys/bin» эквивалентно имени «/ afs / transarc».com / sun4c_55 / bin «. На персональном компьютере под управлением Windows NT то же имя заменяется на» /afs/transarc.com/i386_nt35/bin «.

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

5.0 Услуги цифровой библиотеки

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

Файловая система уже предоставляет некоторые из основных строительных блоков, из которых строятся электронные библиотеки [Kahn95]. Файл — это цифровой объект, который управляет некоторым простым цифровым материалом (содержимым файла) и метаданными (например, владельцем и размером файла). С файлом связаны элементы управления доступом, которые обеспечивают грубые ограничения на использование объекта. Имя файла — это универсальный дескриптор объекта, который идентифицирует файловый сервер, на котором находится объект, и расположение файла на этом сервере.

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

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

Во-вторых, файловая система должна явно указывать каждый объект. Основная цель связывания типа с объектом — ограничить метаданные, хранящиеся с объектом.То есть тип определяет схему для атрибутов метаданных. Тип также предоставляет информацию об операциях, которые могут быть выполнены с объектом. Например, файл данных для календарного приложения поддерживает такие операции, как «Добавить встречу». Таким образом, система типов делает файлы самоописывающими.

За счет использования отношений между типами система типов может приспособиться к разнообразию форматов, которое сопровождает федеративные системы, с минимальной потерей совместимости.В частности, наш опыт показывает, что использование наследования для связывания типов является мощным инструментом для обеспечения максимальной функциональной совместимости в рамках федеративных систем [Bowman97]. Наследование позволяет указать общую роль для файлов с разным форматом. Роль файла определяет схему в базовом типе. Каждый формат управляется подтипом роли, где выполнение операций зависит от формата файла. Кроме того, наследование представляет собой специализацию между типами.Специализация — это тип, который настраивает базовую структуру другого типа. В файловой системе это часто случается, когда одно приложение предполагает, что структура в области файла считается неструктурированной другим приложением, которое работает с файлом. Например, компилятор выбрасывает все комментарии, содержащиеся в файле. Однако приложение, которое управляет средой разработки, предполагает структуру начальных комментариев в файле и извлекает ссылки на функции, имена авторов и историю изменений.

Мета-объекты составляют третье усовершенствование интерфейса файловой системы. Кан и Виленски используют термин «мета-объект» для обозначения объекта, основной целью которого является хранение и управление ссылками на другие объекты [Kahn95]. Есть много вариантов использования метаобъектов в файловой системе. Мета-объект содержит ссылки на все файлы, являющиеся частью программного пакета. Зависимости между пакетами представлены зависимостями между метаобъектами. Мета-объект содержит ссылки на файлы, принадлежащие конфигурации разработки программного обеспечения.Другой мета-объект может относиться к набору изменений, необходимых для преобразования одной конфигурации в другую. Наконец, метаобъекты полезны для управления множественными эквивалентными представлениями файла [Daniel97].

Идентификация и поиск объектов с помощью запросов к цифровому материалу и метаданным значительно упрощает расположение файлов и является последним усовершенствованием интерфейса файловой системы. Одно из применений службы — интеграция местоположения файла с браузерами и оболочками файловой системы.Например, семантическая файловая система встраивает запросы в имя каталога [Gifford91]. Любое приложение может легко найти файлы в дереве каталогов, создав каталог, имя которого является запросом. Встроенный поиск в приложениях — еще одно применение этой службы. Рассмотрим альтернативу папкам почтового ящика, где метаобъекты со связанным запросом представляют динамические представления для коллекции сообщений. Вместо того, чтобы копировать сообщение в каждую соответствующую папку, метаобъекты содержат ссылку на одну копию сообщения. Этот подход поддерживает множественную классификацию сообщений без дополнительных административных затрат на управление множеством копий каждого сообщения.

Разнообразие типов файлов и метаданных усложняет интеграцию служб поиска на основе содержимого с интерфейсом файловой системы. В частности, огромные различия в типах и использовании метаданных означают, что не будет единого стандартного интерфейса для доступа к файлам на основе содержимого. достаточно для всех типов. Например, метаданные, обычно связанные с файлом HDF, который содержит данные спутниковой телеметрии, являются числовыми, хорошо структурированными и будут использоваться для создания специализированных структур просмотра.Напротив, метаданные, связанные с файлом HTML, являются текстовыми и используются в основном для полнотекстового поиска. Кроме того, средства управления доступом создают дополнительную проблему производительности для поиска информации, поскольку количество требуемых проверок авторизации велико.

6.0 Демонстрация

Чтобы продемонстрировать жизнеспособность интеграции файловой системы и технологии цифровых библиотек, мы реализовали объектно-ориентированное расширение файловой системы под названием Synopsis [Bowman96].Традиционный интерфейс файловой системы дополнен унифицированным логическим интерфейсом для безопасного, масштабируемого и распределенного обмена информацией. В дополнение к традиционным нетипизированным файлам, Synopsis определяет интерфейс для типизированного файлового объекта, называемого синопсисом . Файловая система использует статические каталоги для группировки похожих файлов. Синопсис определяет мета-объект, называемый дайджестом , для динамической классификации синопсисов. Дайджест очень похож на представление базы данных. Имена путей служат для идентификации файлов.Для обнаружения файлов Synopsis добавляет адресацию на основе содержимого с помощью запросов к свойствам синопсиса. Для оперативной инкапсуляции Synopsis добавляет в синопсис вызов метода как способ доступа к файлу.

В Synopsis метаданные, связанные с файловым объектом, представлены набором атрибутов. Атрибуты, связанные с синопсисом, разделены на два набора, поиск и состояние, в зависимости от цели. Атрибуты поиска предназначены для хранения метаданных, полезных для поиска и классификации файла.Как правило, атрибуты поиска выводятся из свойств файла — следовательно, название «синопсис» подразумевает, что объект файла предназначен как краткое изложение файла. Атрибуты состояния предназначены для хранения информации, необходимой для реализации метода. Как минимум, состояние содержит информацию о типе синопсиса, его идентификаторе, элементах управления доступом и соответствующем файле.

Synopsis в настоящее время развернут в Transarc. Он управляет примерно 200 000 файлов, включая исходный код программы, документацию по продукту, веб-страницы, сообщения новостей, файлы информации о клиентах и отчеты о дефектах.Через безопасный HTTP-шлюз клиенты, консультанты и специалисты по поддержке продуктов вызывают методы в сводках примерно 10 000 раз в неделю для решения критических (и не очень критических) проблем клиентов.

В дополнение к службам определения местоположения файлов, предоставляемым шлюзом HTTP, мы реализовали несколько приложений, которые упрощают интерфейс с устаревшим программным обеспечением для управления исходным кодом, улучшают обработку электронных сообщений и интегрируют различные файлы научных данных.Мы реализовали сервисы задач и аннотаций, которые упрощают обмен информацией между всеми приложениями. Клиенты службы аннотаций используют ее, чтобы оставлять подсказки об отношениях, существующих между документами.

Другие системы пытаются улучшить интерфейс файловой системы с помощью служб управления контентом. Семантическая файловая система (SFS) использует типы для идентификации преобразователей, которые извлекают и индексируют сводки документов для улучшения местоположения файлов [Gifford91]. В чесноке используются оболочки типизированных объектов, похожие на синопсис, чтобы скрыть неоднородность между набором источников данных (включая файлы) [Roth97].Shore — это объектная база данных, которая предоставляет расширение оболочки для устаревшего доступа через интерфейс файловой системы [Carey94].

7.0 Выводы

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

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

По этой причине мы обращаемся к технологии цифровых библиотек и сервисам промежуточного программного обеспечения, которые она предоставляет для создания коллекций цифровых объектов и управления ими. Такие службы, как расположение файлов на основе содержимого, строго типизированные объекты, представление сложных отношений между документами и внешние метаданные, решают проблемы, которые ограничивают совместную работу в файловых системах. Ключевой особенностью подхода цифровой библиотеки является то, что он носит полностью общий характер. То есть службы определения местоположения метаданных и документов могут применяться ко многим типам данных и предлагают способ интеграции различных приложений управления документами.

Наш опыт работы с Synopsis и его развертыванием в Transarc показывает, что интеграция файловой системы и технологии цифровых библиотек сокращает время на разработку совместных приложений и значительно улучшает интеграцию информации из нескольких репозиториев. Услуги промежуточного программного обеспечения для хранения и управления контентом, предоставляемые Synopsis, стирают различие между приложениями и базовым информационным субстратом; то есть в Synopsis информация становится приложением.

8.0 Ссылки

[Bowman94]	Мик Боуман, Чанда Дарап, Мринал Баруа, Билл Камарго и Сунил Потти. Файловая система для управления информацией. Материалы конференции по интеллектуальным системам управления информацией. Вашингтон. Июнь 1994 г.
[Bowman96]	Мик Боумен и Ранджит Джон. Файловая система Synopsis: от файлов к файловым объектам. Практикум по распределенному объектному и мобильному коду.Бостон, Массачусетс. Июнь 1996 г. Доступно как http://www.transarc.com/~trg/papers/omgw3.html.
[Bowman97]	Mic Bowman. «Управление разнообразием в глобальных файловых системах». Появился на конференции IEEE Metadata ’97. Гринбелт, Мэриленд. Сентябрь 1997 г. Также доступно как http://computer.org/conferen/proceed/meta97/papers/mbowman/mbowman.html.
[Carey94]	Майкл Дж. Кэри, Дэвид Дж. ДеВитт, Майкл Дж. Франклин и др.др., Поддержка постоянных приложений, Международная конференция ACM SIGMOD по управлению данными. Миннеаполис, Миннесота. Май 1994 г.
[Daniel97]	Рон Даниэль и Карл Лагозе. Расширение Warwick Framework: от контейнеров метаданных до активных цифровых объектов. Журнал D-Lib, ноябрь 1997 г. Доступно как http://www.dlib.org/dlib/november97/daniel/11daniel.html.
[Gifford91]	Дэвид Гиффорд, Пьер Жувело, Марк Шелдон и Джеймс О’Тул-младший.Семантические файловые системы. Труды тринадцатого симпозиума ACM по принципам операционных систем. Октябрь 1991 г.
[Howard88]	Дж. Х. Ховард, М. Л. Казар, С. Г. Менес, Д. А. Николс, М. Сатьянараянан, Р. Н. Сидботэм и М. Дж. Уэст. Масштабирование и производительность в распределенной файловой системе. ACM Transactions on Computer Systems, 6 (1), февраль 1988 г.
[Kahn95]	Роберт Кан и Роберт Виленски. Платформа для распределенных служб цифровых объектов.Май 1995 г. Доступно как http://WWW.CNRI.Reston.VA.US/home/cstr/arch/k-w.html.
[Kazar88]	M. L. Kazar. Проблемы с синхронизацией и кешированием в файловой системе Andrew. Материалы зимней конференции Usenix 1988 г. Ассоциация Usenix, январь 1988 г.
[Rein97]	Гейл Рейн, Дэниел МакКью и Джудит Слейн. Случай для функций управления документами в Интернете. Сообщения ACM, 40 (9), сентябрь 1997 г.
[Roth97]	Мэри Торк Рот и Питер Шварц.Не ломайте, завертывайте! Архитектура оболочки для устаревших источников данных. Материалы 23-й конференции VLDB. Афины, Греция. 1997.
[Sidebotham86]	R.N. Сайдботэм. Тома: примитив структурирования данных файловой системы Andrew. В материалах конференции European Unix User Group, август 1986.
[Spasojevic94]	Мирьяна Спасоевич, Мик Боуман и Альфред Спектор. Использование глобальной файловой системы во всемирной паутине.Вторая международная конференция по всемирной паутине. Чикаго, Иллинойс. Октябрь 1994 года.
[Спасоевич96]	Мирьяна Спасоевич и М. Сатьянараянан. Эмпирическое исследование глобальной распределенной файловой системы . ACM Transactions on Computer Systems, 14 (2): 200-222, May 1996.
[Spector89]	Альфред Спектор и Майк Казар. Глобальная файловая служба и экспериментальная система AFS. Unix Review, 7 (3), март 1989 г.

hdl: cnri.dlib / февраль98-bowman Совет

Pro: упростите управление файлами с помощью файлов Salesforce в Lightning Experience

Подключайтесь к серии блогов «Советы по Lightning Experience Pro», чтобы узнать о настройке Lightning Experience и о том, как избежать распространенных ошибок.

Когда вы переходите к Lightning Experience, ваши пользователи могут спросить, почему Lightning Experience позволяет добавлять файлы только одного типа, в то время как в Salesforce Classic есть несколько разных типов: документы, содержимое, вложения и файлы.Ответ в том, что в простоте есть красота. В Lightning Experience Salesforce Files объединяет все пользовательские файлы, документы, контент и вложения в единую систему для упрощения управления и совместной работы. Он также интегрирует доступ к файлам непосредственно в поток вашего бизнеса, поэтому пользователи могут получать нужные им файлы из любого места в приложении. Мы уверены, что никто не упустит сложность работы с разными типами файлов после перехода на Salesforce Files!

В этом посте мы рассмотрим, как различные типы файлов интегрированы в Salesforce Files и как настроить такие вещи, чтобы ваши пользователи быстро чувствовали себя как дома в Lightning Experience.

Особенности файлов Salesforce

Во-первых, давайте взглянем на то, что ваши пользователи могут делать с Salesforce Files в Lightning Experience. Это главная страница «Файлы», центр управления всеми файлами пользователей.

Список связанных файлов позволяет пользователям загружать файлы, которые они хотят связать с записями. Список содержит только файлы Salesforce.

Связанный список «Примечания и вложения» содержит примечания и вложения из Salesforce Classic. Он также может содержать файлы Salesforce.Файлы, добавленные в этот связанный список с помощью Lightning Experience, выгружаются как файлы Salesforce. В программе «Настройка» существует настройка организации, согласно которой файлы, добавленные в этот список в классической версии, выгружаются как файлы Salesforce. Подробнее об этом чуть позже.

При загрузке файла в любой связанный список в Lightning Experience он загружается как файл Salesforce. Можно использовать связанный список «Заметки и вложения», хотя вам все еще нужен доступ к своим старым заметкам и вложениям из Salesforce Classic, но в конечном итоге вы захотите использовать только связанный список файлов и связанный список заметок.

Теперь давайте посмотрим, как различные типы файлов из Salesforce Classic включаются в файлы Salesforce, чтобы вы могли уверенно перейти на Lightning Experience.

Вложения: раскладушки файлового мира

От старых привычек трудно избавиться, но поверьте нам, вложения — это привычка, от которой ваши пользователи хотят избавиться. Зачем использовать файлы Salesforce вместо вложений? Вот краткое изложение преимуществ производительности, которые получают ваши пользователи. Нетрудно заметить, что вложения значительно ограничены по сравнению с файлами Salesforce.

По сути, вложения довольно ограничены по сравнению с файлами Salesforce. Что пользователи могут делать с вложениями? Прикрепите их к записям. Это оно. А вложения существуют только в контексте тех записей, к которым они прикреплены. Их нет в главном списке файлов или в списке связанных файлов. Пользователи не могут делиться ими в Chatter или с другими. Все, что могут сделать пользователи, — это просмотреть и загрузить их.

Просмотр и загрузка вложений в Lightning Experience

В Lightning Experience вложения доступны только для чтения.Пользователи по-прежнему могут просматривать и загружать свои существующие вложения из связанного списка «Заметки и вложения». Но со временем вложения станут устаревшими, поэтому, чтобы замедлить их распространение, пользователи не смогут создавать новые вложения в Lightning Experience.

Наверное, сбивает с толку наличие файлов в двух разных связанных списках в одной и той же записи. В конце концов, вы хотите перестать использовать вложения и связанный список «Заметки и вложения». Для этого мы рекомендуем как можно скорее преобразовать существующие вложения ваших пользователей в файлы.Мы немного поговорим о ваших вариантах работы с вложениями.

Когда вы загружаете файл в Lightning Experience, будь то из связанного списка «Файлы», связанного списка «Примечания и вложения» или где-либо еще, он загружается как файл Salesforce. Это означает, что связанный список «Примечания и вложения» может содержать набор вложений, созданных из файлов Salesforce Classic и файлов Salesforce, загруженных через Lightning.

То же содержание, которое вы знаете и любите

Есть ли у ваших пользователей файлы и папки Salesforce CRM Content в библиотеках Salesforce Classic? Вы будете счастливы, узнав, что вам ничего не нужно делать.В Lightning Experience библиотеки содержимого автоматически преобразуются в файлы Salesforce и доступны из главной страницы файлов через фильтр библиотек.

Пользователи могут перемещать файлы между библиотеками и создавать подпапки внутри библиотек. В настоящее время пользователи переключаются на Salesforce Classic, чтобы создавать библиотеки и управлять ими, а также создавать пакеты содержимого. Но это кратковременное неудобство, потому что мы работаем над добавлением этих параметров в Lightning Experience в не самой будущей версии.

Хотите отправлять доставку контента в Lightning Experience? Без проблем.Для этого есть действие! Прочтите это сообщение в блоге, чтобы узнать, что нужно сделать, чтобы доставка контента работала в Lightning Experience.

Откажитесь от документов

Documents — это устаревший объект с ограниченной полезностью в современном мире файлов, поэтому вкладка «Документы» не подходит для Lightning Experience. Люди обычно использовали документы для таких вещей, как логотипы и другие активы. Если ваша организация использует документы в Salesforce Classic, найдите время, чтобы определить, какие из них вам понадобятся в Lightning Experience.Загрузите их, а затем загрузите в свою библиотеку активов на главной странице файлов.

Контрольный список для успеха: файлы Salesforce в Lightning Experience

Готовы перейти на Salesforce Files в рамках развертывания Lightning Experience, но не знаете, с чего начать? Вот контрольный список для начала.

Добавьте связанный список файлов в макеты страниц. Нужно напомнить о редактировании макетов страниц? Ознакомьтесь с разделом «Добавление связанного списка файлов в макеты страниц» в справке Salesforce.
Настройте связанный список «Примечания и вложения», чтобы файлы, загружаемые пользователями в Salesforce Classic, обрабатывались как файлы Salesforce, а не вложения. Этот параметр гарантирует, что в вашей организации больше не будут создаваться вложения, даже если пользователи все еще работают в классической версии. В программе «Настройка» введите файлов в поле «Быстрый поиск» и выберите Общие параметры . Включить Файлы, загруженные в список связанных вложений для записей, загружаются как файлы Salesforce, а не как вложения .
Укажите файлы на вкладке «Документы» в классической версии, которые вы хотите сохранить. Загрузите их, а затем загрузите в свою библиотеку активов на главной странице файлов.
Преобразуйте существующие вложения вашей организации в файлы Salesforce. Смотрите следующий раздел, чтобы узнать о ваших возможностях.

Преобразовать существующие вложения

Вложения все еще существуют. Но в Lightning Experience они доступны только для чтения, и в какой-то момент в будущем они станут устаревшими. Кроме того, пользователям может быть сложно держать свои вложения и файлы в чистом виде.Чтобы упростить работу, мы рекомендуем преобразовать существующие вложения ваших пользователей в файлы Salesforce. Не волнуйтесь — у нас есть варианты, чтобы помочь вам.

Инструмент преобразования AppExchange: Используйте этот удобный инструмент на AppExchange от Salesforce Labs для преобразования вложений в файлы. Приложение бесплатное и простое в использовании.

Инструмент преобразования API: Используете профессиональную версию Salesforce? Приложение для преобразования AppExchange вам не подходит, но у нас есть решение API, которое вы можете использовать вместо него.

Закройте книгу вложений

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

Но помните: Связанный список «Заметки и вложения» также включает классические заметки вашей организации. Как мы уже говорили в публикации «Ускорение ведения заметок с расширенными заметками в Lightning Experience», перед удалением связанного списка «Заметки и вложения» убедитесь, что вы также преобразовали классические заметки пользователей в расширенные заметки.

Дополнительные ресурсы

Ознакомьтесь с другими советами по настройке и настройке Lightning Experience, следуя серии Pro Tip:

Краткая история хранения данных

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

разработка автоматизация делопроизводства
появление сети
появление распределенных приложений

Сравнительная таблица: блочное, файловое и объектное хранилище

Глубокое погружение в основы компьютерных систем

История носителей данных , от перфорированных карт до недавних попыток хранить информацию в цепях ДНК, хорошо задокументирована.Диски, ZIP-диски, CD-ROM, DVD, флэш-память, диски SATA, SSD или NVMe … почти все мы держали в руках одну или несколько из этих эволюционных систем хранения. Этот прогресс еще не привел к полной передаче данных в «облако», о чем свидетельствует сохранение архивирования на магнитных лентах. О смерти таких решений было объявлено преждевременно, ведь объемы и сегодня растут!

Параллельная история режимов хранения , от блочной до объектной, менее известна, вероятно, потому, что ее корни лежат в нижних уровнях ИТ.За прошедшие годы между аппаратным и программным обеспечением было добавлено так много уровней абстракции, что раскрытие их истории может быть похоже на упражнение в спелеологии [BHJ2] или археологии. Давайте вместе отправимся в путь открытий!

Вначале был блок

Наименьший блок памяти в компьютерной системе с исходным размером 4 КБ (килобайт), или 4096 байтов, и столько же областей памяти, эквивалентных 0 или 1, через которые информация можно хранить в цифровом виде. Изначально хранилище не могло быть отделено от сервера. Жесткий диск содержал информацию, считываемую и записываемую локально машиной, через материнскую плату с физической точки зрения и через операционную систему с логической точки зрения. Базовый. За исключением того, что размер файлов, обрабатываемых компьютерами, продолжал расти. Когда в 1970-х годах были разработаны первые микрокомпьютеры, 8-дюймовая дискета считалась «высокоскоростным» запоминающим устройством и могла содержать всю операционную систему!

ФАЗА 1

Отделите систему хранения от сервера
На большинстве персональных компьютеров всегда был один жесткий диск.С другой стороны, серверы были быстро спроектированы для размещения нескольких дисков . Так было сделано:
Сначала для увеличения емкости хранилища
Затем для защиты данных (с появлением RAID, концепция которого впервые была определена в конце 1980-х годов)
И в конечном итоге решить проблемы с производительностью
Однако это вертикальное изменение размера (горизонтальное масштабирование) рано или поздно достигает своих пределов : пределов серверного корпуса .
Первым технологическим прорывом стало отделение системы хранения от сервера и предоставление ей возможности использовать диски, отличные от тех, которые размещены внутри его собственного шасси.Это привело к появлению Direct Attached Storage (DAS) , который дает компьютеру возможность получить доступ к диску, подключенному к машине как устройству. Затем появилась Storage Area Network (SAN) , подключенная к сети система жестких дисков, которая позволяет машине получать доступ к хранилищу через протокол Fibre Channel в режиме клиент / сервер. Затем стало возможно, что разделяет пространство хранения между несколькими серверами. Но пока нельзя читать или писать одновременно с нескольких машин из-за сложности управления конкурирующими записями.
Однако отделение хранилища от серверов стало значительным шагом вперед: это позволило разработать первую «сложную» архитектуру для обеспечения высокой доступности приложений . По сути, база данных размещается в общем хранилище между главной и подчиненной машинами, готовым взять на себя управление в случае недоступности. Этот активный / пассивный режим будет быстро оптимизирован с помощью активного / пассивного кроссовера : две машины работают одновременно и могут заменять друг друга в случае проблемы, временно поглощая нагрузку друг друга (при условии, что у них есть пропускная способность, поскольку затем нагрузка удваивается).Это позволяет не оставлять машину в спящем режиме, который в лучшем случае будет использоваться всего несколько минут в год. А использование двух серверов на 50% от их мощности упрощает работу с любыми пиковыми нагрузками.
Медленная эволюция жестких дисков
Основным достижением жестких дисков с магнитными пластинами, появившихся на свет более 60 лет назад, стало увеличение их емкости за счет увеличения их плотности. Только с появлением флеш-технологии, недавно демократизированной с помощью SSD и NVMe-дисков, был достигнут настоящий прорыв с точки зрения задержки (времени доступа к данным) и пропускной способности, что привело к большей реактивности машины и большему количеству операций ввода-вывода в секунду (ввод / вывод). количество операций вывода в секунду).
ФАЗА 2

Обобщение файловых систем
В связи с развитием практики автоматизации делопроизводства и необходимостью совместной работы путем совместного использования и одновременного редактирования документов и папок файловые системы неизбежно стали более широко использоваться. Хранение в файловом режиме (или «файловом»), вероятно, легче всего понять. Его принцип точно такой, какой вы можете себе представить, столкнувшись с файловым проводником (или Finder для энтузиастов Mac OS). Данные хранятся в папках и подпапках , образуя древовидную структуру в целом.Затем доступ к данным осуществляется по более длинному или более короткому пути , в зависимости от глубины древовидной структуры. Этот «иерархический» способ хранения все еще является наиболее распространенным для систем прямого и сетевого хранилища (NAS).
Вслед за ростом файловых систем появились новые протоколы для организации связи между серверами и общими хранилищами.
Сетевая файловая система (NFS) была разработана Sun Microsystems в 1984 году.
Server Message Block (SMB) был первоначально создан IBM в 1985 году, а затем популяризирован Microsoft, которая интегрировала его в качестве системы обмена файлами по умолчанию в Windows. Microsoft переименовала его в Common Internet File System (CIFS) в 1996 году, а в 2006 году вернулась к исходным инициалам SMB. Samba, реализация протокола SMB с открытым исходным кодом, впервые появилась публично в 1997 году и является наиболее известной и широко используемой. предприятиями.
Протокол передачи файлов (FTP) стал предпочтительным методом для новых веб-приложений, в частности, для загрузки файлов в сочетании с использованием NAS.Он идеально соответствовал потребности в решении внутреннего хранилища, совместно используемом несколькими серверами для создания n-уровневых веб-приложений. Именно это привело к успеху таких решений, как решения, разработанные NetApp, американской компанией, которая в 2000-х годах быстро выросла и стала второй по величине компанией в секторе хранения данных между отраслевыми гигантами Dell и HP.
Да здравствует блочное хранилище!
Файловая система, которая создает виртуальную древовидную структуру, представляет собой уровень абстракции, который накладывается на «блочное устройство» (управление блочной записью на уровне ядра).Это очевидное улучшение по причинам, указанным выше, но файловая система не уничтожила блочное хранилище. И не зря: добавление уровня абстракции приводит к снижению производительности ввода-вывода . Отчасти это связано с расчетами, необходимыми для поддержания и представления древовидной структуры. На производительность также влияет необходимость управления системой для одновременной записи [BHJ3], которая необходима, если вы собираетесь разрешить нескольким рабочим станциям или серверам одновременный доступ к данным.
В результате блочное хранилище продолжает существовать , особенно для хранилища больших баз данных, к которым осуществляется доступ и которые интенсивно изменяются , или для высокопроизводительных файловых систем виртуальных машин .
Со временем решения для хранения, использующие блочное хранилище и файловую систему, улучшились с технологической точки зрения (повышение производительности как для носителей, так и для контроллеров). Самое главное, провайдеры добавили такие услуги, как защита данных.Они варьируются от различных типов RAID, которые оптимизировали как избыточность, так и потребление пространства, до расширенных функций, таких как синхронное или асинхронное копирование данных между двумя отсеками или моментальные снимки всех томов.
Добавление этих дополнительных услуг помогло сохранить высокие затраты : экономия от масштаба, например, связанная с увеличением дисковой емкости, в значительной степени компенсировалась растущей сложностью решений для хранения данных. Это была эпоха, когда проприетарные решения управляли рынком хранения данных: специальное оборудование, управляемое проприетарным программным обеспечением, которое было поистине черным ящиком для пользователей.Высокая стоимость складских площадок усугублялась неизбежными контрактами на техническое обслуживание. Фактически, когда возникали проблемы, организациям было практически невозможно решить их без помощи производителя. Таким решениям для хранения также не хватало гибкости: в частности, было невозможно распределить уровни данных в одной и той же системе хранения.
Но, возможно, это было и более простое время: разные системы обладали схожими возможностями, и если у вас был бюджет, вашему ИТ-директору просто нужно было выбрать предпочтительного поставщика.Честно говоря, выбор в меньшей степени зависел от технических характеристик решений, чем от талантов торговых представителей вендора!
ФАЗА 3

Хранилище объектов — безграничная прокрутка и программный интеллект
В то время как объем данных, которые необходимо сохранить, постоянно растет (кривая теперь экспоненциальная), ограничения файловой системы постепенно проявляются. Файловая система — или, точнее, служба диспетчера распределенных блокировок — не может управлять одновременными подключениями с тысяч компьютеров.И , если объем данных может достигать петабайтного уровня, количество файлов не неограниченно . Настройка файловой системы требует кэширования древовидной структуры одновременно с ее изучением пользователем. Когда файловая система содержит большое количество файлов, такое кэширование древовидной структуры требует большого объема оперативной памяти и может существенно повлиять на производительность. В конечном итоге: системы хранения на основе файловой системы достигают своих пределов до того, как их емкость будет полностью использована (падение производительности становится значительным после достижения 85% -ной степени заполнения).
Единственное решение — увеличить количество систем хранения, то есть создать бункера . Это означает, что миграцию данных необходимо выполнять регулярно, как только заполняется хранилище. Это рискованные операции, в которых задействованы целые команды. С другой стороны, большая часть недавно сгенерированных данных — это так называемые неструктурированные данные . Проще говоря, это вся информация, которая не организована в базы данных: файлы автоматизации делопроизводства, истории электронной почты, изображения, видео, журналы…
Технологический прорыв, который стал результатом этих новых задач, заключался в передаче интеллектуальных данных от аппаратного обеспечения (которое становилось все более сложным и дорогим) в программное обеспечение. Программно-определяемое хранилище — это своего рода логическое продолжение движения, которое произвело революцию в вычислениях (с виртуальными машинами) и сети (с программно-определяемым сетевым подходом), прежде чем разрушить мир хранилищ. «Программное обеспечение пожирает мир», известное пророчество Марка Андреессена в 2011 году, означало, что все компании, независимо от сферы их деятельности, должны были стать издателями программного обеспечения — в противном случае им угрожала бы Uberisation.В инфраструктурном бизнесе эта пословица верна уже несколько лет.
Преимущества распределенного хранилища
Идея объектного хранилища заключается в использовании стандартных серверов (x86 или ARM) для создания плоской структуры , в которой файлы фрагментированы и распределены по всем узлам кластера , согласно по разной логике. В большинстве случаев это алгоритм сегментирования, который обрабатывает данные, распределяя данные относительно случайным образом, но возможны и другие методы, как показывает система интеллектуального размещения, реализованная в нашем решении OpenIO Object Storage.
Каждый объект имеет уникальный идентификатор и метаданные . Система использует этот идентификатор и метаданные для извлечения файлов и повторной сборки фрагментов , распределенных между несколькими машинами.
Этот принцип распределенного хранилища дает множество преимуществ:
бесконечная масштабируемость теоретически
подробнее экономичная защита данных (программа кодирования стирания, заменяющая работу RAID-контроллера)
способность (теоретически, еще раз) работать со стандартными серверами и разнородное оборудование
улучшенная балансировка нагрузки
способность максимально использовать ресурсные возможности
Доступ к данным через API также имеет то преимущество, что упрощает разработку приложений , которые будут использовать данные.В принципе, все возможно с помощью трех команд: GET, PUT и DELETE. А часть обработки данных может выполняться непосредственно в системе хранения благодаря анализу метаданных. Например, в случае онлайн-хранилища фотографий веб-приложение может предлагать пользователю динамические коллекции (по дате, по местоположению, по типу камеры …) без управления этими операциями сортировки и группировки. Все, что ему нужно сделать, это позвонить через API, чтобы вывести список фотографий с соответствующим атрибутом в метаданных.Затем он представляет пользователю приложения все фотографии, которые система объектного хранилища возвращает в ответ на этот вызов. Для таких применений, как большие данные, эта возможность динамически генерировать тематические коллекции данных на основе того, что вы хотите изучать, является ценным активом.
Распределенные системы: идея из мира исследований
Первые исследования концепции объектного хранилища датируются 1996 годом. Но идея запуска дешевых серверов и объединения их мощностей с помощью программного модуля, отвечающего за распределение задач по всем узлам сети, еще старше.
НАСА , как и многие исследовательские центры по всему миру, с 1960-х годов оснащалось суперкомпьютерами — большими многотонными машинами стоимостью в несколько миллионов долларов. Самыми известными из них были суперкомпьютеры Cray, которые доминировали на рынке между 1970-ми и 1990-ми годами. В 1994 два инженера НАСА, Томас Стерлинг и Дональд Беккер , произвели революцию в мире высокопроизводительных вычислений, изменив парадигмы. Вместо того, чтобы полагаться на все более эффективное и дорогое оборудование, у двух инженеров возникла идея создать вычислительную сеть , состоящую из множества стандартных компьютеров, работающих на свободных операционных системах (GNU-Linux в целом).Как называется это изобретение? Beowulf Cluster , который сейчас широко используется в исследовательском мире.
В другой области, Google обнародовал в 2003 принцип распределенной файловой системы, разработанной для собственного использования: Google File System . Эта архитектура, разработанная для обеспечения масштабируемости для хранения поисковых индексов, была первым шагом на пути к хранению объектов. Единственными ключевыми вещами, которые не хватало, были метод доступа к данным с помощью уникального идентификационного ключа (так называемое хранилище с адресом содержимого) и более сложные механизмы сегментирования для интеллектуального разбиения данных в кластере.
Что дальше в развитии систем хранения данных?
Есть ли шанс на появление новой парадигмы, которая снова произведет революцию в способах хранения и использования данных? Нет ничего менее уверенного: три существующие модели — блочное хранилище, файловая система и хранилище объектов — покрывают все текущие потребности рынка. У объектного хранилища, которое появилось совсем недавно, вероятно, самое светлое будущее с точки зрения объема данных. Но для того, чтобы хранилище объектов стало действительно широко распространенным, еще предстоит проделать работу, чтобы выполнить все обещания концепции и повысить удобство использования.