Категория данных имен файлов


К категории имен файлов относятся структуры данных, в которых хранятся имена всех файлов и каталогов. В этом разделе описано, где хранятся данные и как их анализировать.
Общие сведения
В ExtX существует несколько способов присваивания имен файлам и каталогам; в этом разделе будут рассмотрены три из них.
В первом подразделе рассматриваются записи каталогов — основные структуры данных, используемые при назначении имен. Затем мы рассмотрим жесткие и мягкие ссылки, а также хеш-деревья.
Записи каталогов
Каталог ExtX практически ничем не отличается от обычного файла, если не считать установки специального значения типа в индексном узле. В блоках, выделенных каталогам, содержится список структур данных, называемых записями каталогов. Запись каталога представляет собой простую структуру данных с именем файла и адресом индексного узла, в котором хранятся метаданные файла. Размер каталога соответствует количеству выделенных блоков и не связан с количеством реально существующих файлов.
Каждый каталог начинается с записей «.» и «..», обозначающих текущий и родительский каталог соответственно. За ними следуют записи всех файлов и подкаталогов в данном каталоге. Корневой каталог всегда размещается в индексном узле 2.
Запись каталога имеет динамическую длину, потому что файл может обладать именем произвольной длины, от 1 до 255 символов. По этой причине в структуре данных присутствует поле, определяющее длину имени и местонахождение следующей записи каталога. Длина записей округляется до числа, кратного 4. На рис. 14.6 изображен каталог с тремя файлами. Первые две записи предназначены для каталогов «.» и «..», а последняя запись ссылается на конец выделенного блока. Пространство за файлом c.txt не используется.
При удалении файла или каталога его имя требуется модифицировать, чтобы ОС не пыталась выводить информацию об этом файле. ОС скрывает запись каталога, увеличивая длину предыдущей записи, чтобы она ссылалась на запись после скрываемой. Так, на рис. 14.6(B) файл b.txt был удален, а указатель в a.txt был увеличен и переведен на c.txt. При выводе содержимого каталога запись b.txt пропускается, но данные в ней еще существуют.
При создании новой записи ОС анализирует каждую существующую запись и сравнивает ее длину с длиной имени. Кроме имени, каждая запись каталога содержит 8 байт в статических полях, поэтому минимальная длина записи определяется увеличением длины имени на 8 и округлением результата до величины,

кратной 4. Если зарезервированная длина записи превышает необходимую на величину, превышающую размер добавляемой записи, запись размещается в неиспользуемом пространстве. Для примера рассмотрим новый каталог с 4096-байтовым блоком, содержащим записи «.» и Параметры этих записей перечислены в табл. 14.1.
А)


1

г


г

1

г

1

г

лг

inode 410

inode 900

a.txt inode 419

b.txt inode 429

c.txt inode 482



В)






г ч

г


Г Ў

inode 410

inode 900

a.txt inode 419

b.txt inode 429

c.txt inode 482


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


Таблица 14.1. Параметры записей только что созданного каталога

Имя

Длина имени

Длина записи


1

12


2

4084


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

Имя

Длина имени

Длина записи


1

12


2

12

Filel.dat

8

4072


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

Далее приводится результат выполнения fIs для одного из каталогов тестового образа. В выходных данных присутствует один удаленный файл (он помечен префиксом *). В первом столбце отображается тип файла — сначала по данным из записи каталога, затем по данным из индексного узла. Обратите внимание на совпадение этих типов у удаленного файла; возможно, индексный узел еще не был выделен повторно: f1s -f linux-ext3 -a ext3.dd 69457 d/d 69457: d/d 53248:
г/г 69458:              acbdefg.txt
г/г * 69459:              file two.dat
d/d 69460:              subdirl
r/r 69461:              RSTUVWXY
Ссылки и точки монтирования
В ExtX поддерживаются как жесткие, так и мягкие ссылки, при помощи которых пользователи могут определять несколько имен для файлов и каталогов. Жесткая ссылка представляет собой дополнительное имя для файла или каталога, принадлежащего той же файловой системе. После создания жесткой ссылки невозможно отличить ее от исходного имени. Чтобы создать жесткую ссылку, ОС выделяет новую запись каталога и создает в ней указатель на исходный индексный узел. Счетчик ссылок в индексном узле увеличивается на 1, отмечая появление нового имени. Файл будет удален лишь после удаления всех жестких ссылок на него.
Помните, что записи «.» и «..» в каждом каталоге представляют собой жесткие ссылки на текущий и родительский каталоги. По этой причине счетчик ссылок каталога равен как минимум 2 + количество содержащихся в нем подкаталогов.
Мягкие ссылки также определяют альтернативные имена для файлов и каталогов, но они могут выходить за пределы файловых систем. Для создания мягких ссылок ОС использует особую разновидность файлов, называемых символическими ссылками. Полный путь к приемному файлу или каталогу хранится либо в блоках, выделенных файлу, либо в индексном узле, если длина пути меньше 60 символов. В следующей главе будут приведены примеры структур данных, содержащих символические ссылки.
Примеры жестких и мягких ссылок показаны на рис. 14.7. Слева изображена жесткая ссылка hardlink.txt, указывающая на файл filel.txt. Справа изображена мягкая ссылка на тот же файл, но на этот раз в схеме появляется промежуточный уровень. Файл softlink.txt обладает собственным индексным узлом, содержащим путь к файлу. Обратите внимание: на рисунке (В) у обоих индексных узлов счетчик ссылок равен 1. В действительности символическая ссылка сохранит адрес /filel.txt в индексном узле, потому что путь короче 60 символов.
Как упоминалось в главе 4, в каталогах UNIX могут храниться как файлы, так и точки монтирования томов. Рассмотрим каталог dirl из файловой системы с именем FS1. Если файловая система FS2 смонтирована в каталоге dirl, при переходе пользователя в этот каталог и выводе его содержимого будут выведены файлы из FS2. Даже если в FS1 каталог dirl содержит собственные файлы, при монтировании FS2 они отображаться не будут. На рис. 14.8 (А) каталог dirl содержит три графических файла, но на рис. 14.8 (В) пользователь видит вместо них три файла из корневого каталога тома FS2.

А)              В)

Блок 450              Блок              450              Блок              967
Рис. 14.7. Жесткая (А) и мягкая (В) ссылки на файл filel.txt
Для эксперта это означает, что он должен знать, где монтируются файловые системы. Если вы ищете конкретный файл, возможно, его удастся найти лишь после обращения к нескольким файловым системам, потому что разные каталоги могут находиться на разных томах. Многие современные программы анализа не отображают содержимое каталогов в точке монтирования, поэтому вам придется самостоятельно определять, какой том здесь должен находиться. С другой стороны, это позволяет увидеть исходное содержимое каталогов в точках монтирования. В одном из методов сокрытия информации файлы создаются в каталоге, в котором затем монтируется том; для случайного наблюдателя такие файлы останутся незамеченными.
Хеш-деревья
При создании файловой системы вместо описанной реализации на базе списков пользователь может выбрать реализацию на базе хеш-деревьев. Если файловая
система использует хеш-деревья, в суперблоке должен быть установлен блок совместимой функции. Хеш-деревья также используют структуры данных записей каталогов, но хранят их в отсортированном порядке.
Хеш-деревья ExtX сходны с В-деревьями, упоминавшимися в главе 11; за информацией о том, как деревья используются в каталоге, обращайтесь к этому разделу. Главное различие между хеш-деревьями и В-деревьями состоит в том, что в хеш-деревьях файлы сортируются по хеш-кодам имен файлов, а не по самим именам. В ExtX реализована экспериментальная поддержка В-деревьев, аналогичных В-деревьям NTFS, но в этой главе она не обсуждается, потому что эта возможность еще не стала стандартной.
Каталог, использующий хеш-дерево, состоит из нескольких блоков, каждый из которых представляет один узел дерева. Каждый узел содержит файлы с хеш- кодами, значения которых входят в заданный интервал. Первый блок дерева соответствует корневому узлу с записями каталогов «.» и В остальных записях первого блока хранятся дескрипторы узлов, содержащие хеш-код и адрес блока. По дескрипторам узлов ОС определяет блок, к которому следует обратиться за заданным хеш-кодом.
На рис. 14.9 показан пример хеш-дерева. Первый блок содержит заголовок и дескрипторы узлов, а второй и третий — записи каталогов для файлов. ОС, не поддерживающая хеш-деревья, обработает записи всех блоков, не зная, что они хранятся в отсортированном порядке.
Индексное хеш-дерево содержит до трех уровней. Структуры данных дескрипторов узлов и пример каталога приводятся в главе 15.

Алгоритмы выделения
При создании нового имени файла Linux использует стратегию выделения первой доступной записи. ОС последовательно проверяет каждую запись каталога от его начала. На основании длины имени вычисляется необходимый размер записи, который сравнивается с зарезервированным. Если два размера не совпадают, ОС считает, что либо запись находится в конце блока, либо длина была увеличена для пропуска удаленной записи. В обоих случаях ОС пытается включить имя в неиспользуемую область. Если не существует ни одной неиспользуемой области,
размер которой был бы достаточным для хранения имени, то имя присоединяется в конец списка. Новые блоки выделяются по мере надобности, а их содержимое стирается перед использованием. В Linux записи не могут пересекать границы блоков. В других ОС могут использоваться другие стратегии выделения. При использовании хеш-деревьев файл добавляется в блок, соответствующий хеш-коду файла.
При удалении файла длина предыдущей записи увеличивается таким образом, чтобы она ссылалась на запись, следующую за удаленной. Это единственное действие, которое переводит запись в свободное состояние. В файловой системе Ext2 Linux стирает указатель индексного узла, в Ext3 это не делается. Перестановка неиспользуемых записей с целью сжатия каталога не производится.
Методы анализа
Анализ данных в категории имен файлов обычно связан с выводом информации о содержимом каталога с целью поиска конкретного файла (или файлов) по заданному шаблону. Процесс начинается с поиска корневого каталога; в ExtX это делается несложно, потому что корневой каталог всегда находится в индексном узле 2. Каталоги в целом похожи на файлы, за исключением того, что в их индексных узлах устанавливается специальный признак типа. Обнаруженное содержимое каталога обрабатывается как последователь структур данных записей каталогов. Если просматриваются только выделенные записи, следует обработать текущую структуру данных каталога, сместиться вперед на ее указанный размер и обработать следующую запись. Процесс повторяется до конца блока.
Если наряду с существующими файлами потребуется обработать свободные записи, указанный размер записи игнорируется; вместо него вычисляется фактическая длина записи, которая и определяет величину смещения. Например, если последний символ имени находится в байте 34, то переход осуществляется к байту 36. После перехода к границе следует отобразить содержимое на структуру данных записи каталога и провести простейшие проверки того, могут ли данные относиться к записи каталога. Если проверка дает положительный результат, запись обрабатывается, а если нет — следует сместиться еще на 4 байта и проверить новую запись. Эта процедура в конечном счете приведет к границе, указанной в предыдущей записи каталога.
На рис. 14.10 изображены две выделенные записи, между которыми находятся две свободные записи. Между записями каталогов остается неиспользуемое пространство, поэтому найти имена простым переходом к следующей 4-байтовой границе после каждой записи не удастся.


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

В некоторых ситуациях в файловой системе требуется провести поиск блоков, ранее использовавшихся каталогами. Для этого следует проанализировать первые 24 байта каждого блока и определить, присутствуют ли в них записи «.» и «..». Если записи будут обнаружены, значит, это первый блок каталога. Linux всегда выделяет записи каталогов на границах блоков, поэтому в более общем варианте поиска начальные байты могут анализироваться на предмет любого имени файла, не только «..».
Значения указателей позволяют сделать некоторые предположения относительно порядка удаления файлов. На рис. 14.11 показаны шесть возможных комбинаций удаления трех смежных файлов. В верхней части рисунка изображено начальное состояние с четырьмя выделенными записями каталога. Число под каждым блоком представляет «адрес» записи, введенный для удобства описания каждого сценария. Серые блоки изображают свободные записи, а числа — порядок их удаления. Например, в сценарии (А) первым был удален файл в записи 1, а длина записи 0 была увеличена так, чтобы она ссылалась на запись 2. Затем была удалена запись 2, а длина записи 0 была увеличена до ссылки на запись 3. Наконец, запись 3 была удалена, а длина записи 0 была увеличена так, чтобы она ссылалась на запись после 3. Показанное состояние (А) отличается от всех остальных возможных комбинаций последовательности удаления этих файлов.



2
Рис. 14.11. Шесть комбинаций относительного порядка освобождения трех смежных записей каталога. Только последовательности 1-3-2 и 2-3-1 приводят к одному конечному состоянию
Взглянув на конечные состояния всех шести сценариев, вы увидите, что они совпадают только в ситуациях (В) и (D). В обоих случаях можно определить, что средний файл был удален последним. Процедура анализа описана далее в разделе «Сценарий анализа».
Факторы анализа
В ExtX найти имена удаленных файлов несложно, а в Ext3 номер индексного узла не стирается; возможно, это позволит получить информацию о времени удаления

файла. В Linux структура записи каталога остается в свободном состоянии до тех пор, пока не будет создан новый файл с такой же или меньшей длиной имени. Следовательно, записи каталогов, в которых хранились данные файлов с короткими именами, в общем случае стираются не так быстро, как записи файлов с длинными именами. В других ОС могут применяться другие методы выделения и даже схемы сжатия каталогов для сокращения их размеров. Программа fsck для Linux упаковывает каталоги и исключает из них неиспользуемое пространство.
При обнаружении имени удаленного файла дальнейший анализ требует осторожности. Если индексный узел файла был выделен заново, метаданные уже не относятся к удаленному имени. Не существует простого способа определить, был ли индексный узел выделен заново с момента удаления имени файла. В одном из методов тип файла в записи каталога сравнивается с признаком типа в индексном узле. Скажем, если в записи каталога указан тип каталога, а в индексном узле — тип обычного файла, скорее всего, индексный узел был выделен заново. По этой причине в выходные данные программы fls из пакета TSK включаются признаки типа как из записи каталога, так и из индексного узла.
Структуры записей каталогов могут использоваться для хранения скрытых данных. Пространство между последней записью каталога и концом блока не используется; теоретически в нем могут размещаться данные. Это особенно справедливо при использовании хеш-деревьев, потому что первый блок содержит небольшой объем административных данных, а остальная часть не используется. Впрочем, это довольно рискованный метод сокрытия данных, потому что ОС может стереть информацию при создании нового файла.
Сценарии анализа
В этом разделе приводятся два сценария, демонстрирующие методику использования низкоуровневой информации из записей каталогов ExtX. В первом сценарии определяется исходное местонахождение файла, а во втором — возможный порядок удаления файлов.
Исходное местонахождение перемещенного файла
Во время анализа системы Linux, подвергшейся взлому, обнаружен файл snif- ferlog-l.dat, содержащий сетевые пакеты. Другие файлы каталога обладают именами вида log-001.dat и не содержат сетевых данных. Содержимое каталога выглядит так: fls -f linux-ext3 ext3-8.dd 1840555

г/г

1840556:

log-001.dat

г/г

1840560:

log-002.dat

г/г

1840566:

log-003.dat

г/г

1840569:

log-004.dat

г/г

32579:

snifferlog-l.dat

г/г

1840579:

log-005.dat

г/г

1840585:

log-006.dat


Чтобы найти исполняемый файл, который мог использоваться при создании этого файла, мы проводим поиск полного пути к этому файлу. Исполняемые файлы иногда содержат имена открываемых ими файлов, однако в данном случае поиск оказался безуспешным. В конце концов, замаскировать имя открываемого файла
внутри файла программы совсем несложно. Уже собравшись перейти к другой части системы, мы вдруг замечаем странную последовательность адресов индексных узлов в листинге.
У родительского каталога и остальных файлов адреса индексных узлов находятся где-то около 1 840 500, но файл snifferlog-l.dat обладает адресом 32 579. Согласно стратегии выделения, используемой в Linux, файлы обычно создаются в индексных узлах той же группы, к которой принадлежит родительский каталог. Следовательно, либо файл snifferlog-l.dat был изначально создан в другом родительском каталоге, а потом перемещен в текущий каталог, либо он был создан в текущем каталоге, а группа блоков была заполнена до предела.
По результатам fsstat мы определяем, что каталог журналов принадлежит к группе блоков 113, в которой 99 % индексных узлов и 48 % блоков свободны. Маловероятно, чтобы группа была заполнена в момент создания файла, если только с того момента не произошло массовое удаление файлов:
Group: 113:
Inode Range: 1840545 - 1856832 Block Range: 3702784 - 3735551 Free Inodes: 16271 (99*)
Free Blocks: 15728 (48*)
Более подробный анализ индексного узла snifferlog-l.dat (32 579) показывает, что узел входит в группу блоков 2:
Group: 2:
Inode Range: 32577 - 48864 Block Range: 65536 - 98303 Free Inodes: 16268 (99*)
Free Blocks: 0 (0*)
Напрашивается предположение, что файл был создан в каталоге группы блоков 2, а затем перемещен в группу блоков 113. Таким образом, мы попробуем найти в группе блоков 2 каталоги, которые могли бы быть родительскими каталогами по отношению к snifferlog-l.dat. В пакете TSK для решения этой задачи используется программа ils, выводящая подробную информацию об индексных узлах из заданного интервала. При запуске мы задаем интервал для группы блоков, в которой производится поиск, и отфильтровываем все результаты, не относящиеся к каталогам. Ключ -т преобразует данные режима в наглядный формат, понятный для пользователя, а ключ -а ограничивает поиск используемыми индексными узлами. Утилита grep отфильтровывает все результаты, не относящиеся к каталогам (по содержимому пятого столбца). ils -f linux-ext3 -m -a ext3-8.dd 32577-48864 | grep "|d"
lt;ext3-8.dd-al1ve-32577gt;|0|32577|16893|drwxrwxr-x|4[500|500|0|4096|
lt;ext3-8.dd-al1ve-32655gt;(0|32655|16893|drwxrwxr-x|2|500|500|0|4096|
lt;ext3-8.dd-al i ve-32660gt;101325771168771drwxr-xr-x121500150010140961
Первый столбец содержит фиктивное имя для каждой записи. Свободные записи помечаются строкой «dead», а выделенные — строкой «alive». Третий столбец содержит адрес индексного узла. Обычно результаты ils обрабатываются утилитой mactime для построения временных диаграмм, поэтому их формат не слишком удобен для пользователя.
Для просмотра трех каталогов мы воспользуемся программой fls. Каталог в индексном узле 32577 представляется наиболее перспективным.
fls -f 1iлих-ext3 ext3-8.dd 32577 г/г 32578:              onlyjive_twice.mp3
г/г 32582:              goldfinger.mp3
г/г 32580:              1ic_to_kil1.mp3
r/r 32581:              diamonds_forever.mp3
На первый взгляд похоже на невинный каталог с музыкой из фильмов о Джеймсе Бонде в формате MP3... но обратите внимание на индексные узлы и вспомните, что мы знаем о стратегиях выделения индексных узлов и записей каталогов. При выделении индексных узлов используется стратегия поиска первого доступного узла в группе блоков. Файл с содержимым сетевых пакетов находился в индексном узле 32 579, расположенном между only_live_twice.mp3 и lic_to_kill.mp3. Также обратите внимание, что goldfinger.mp3 обладает большим номером индексного узла, чем остальные файлы, и находится в середине каталога. Более того, длина имени goldfinger.mp3 равна 14 символам, а длина snifferlog-l.dat — 16 символам; это означает, что оба файла поместились бы в записи каталога одного размера.
При анализе файлов выясняется, что файл onlyjive _twice.mp3 является исполняемым, а другие файлы содержат журналы сетевых пакетов в том же формате, что и snifferlog-l.dat. Кроме того, временные штампы only_live_twice.mp3 предшествуют временным штампам snifferlog-l.dat, а временные штампы lic_to_kiU.mp3 следуют за snifferlog-l.dat.
На основании собранной информации выдвигается следующая гипотеза: файл snifferlog-l.dat был создан после файла only_live_twice.mp3, после чего был создан файл lic_to_kill.mp3. Через некоторое время после создания файла diamonds_for

ever.mp3 файл snifferlog-l.dat был перемещен в каталог, находящийся в группе блоков ИЗ. После его перемещения был создан файл goldfinger.mp3, который заменил запись каталога и получил следующий доступный индексный узел. М- и С-время индексного узла 32 577 совпадают с данными файла goldfinger.mp3, причем в обоих случаях они следуют за временными штампами файла snifferlog- dat. Ситуация показана на рис. 14.12: запись каталога в группе ИЗ ссылается на индексный блок в группе 2. Мы все еще не знаем, как произошло перемещение файла и всегда ли он существовал под текущим именем или ранее он был замаскирован под МРЗ-файл. Возможно, анализ исполняемого файла прольет свет на эти вопросы.
Порядок удаления файлов
В процессе анализа системы Linux был обнаружен каталог с именем /usr/local/ .oops/. Для системы Linux такой каталог нетипичен, поэтому мы просмотрим его содержимое. В каталоге обнаруживаются восемь удаленных файлов; все соответствующие индексные узлы были выделены новым файлам, что основательно усложнит процесс восстановления. Впрочем, сейчас нас интересует исключительно способ удаления файлов. В результате анализа записей каталогов были получены значения, представленные в табл. 14.3. Имена приводятся в порядке их следования в каталоге.
Таблица 14.3. Параметры свободных записей каталогов в рассматриваемом сценарии

Байт

Имя

Указанная длина

Необходимая длина

12


1012

12

24

config.dat

20

20

44

readme.txt

104

20

64

allfiles.tar

20

20

84

random.dat

64

20

104

mytools.zip

44

20

124

delete-files.sh

24

24

148

sniffer

876

16

164

passwords.txt

860

860


По этим данным можно сделать ряд общих наблюдений. Если указанная длина записи свободной записи каталога соответствует ее фактической длине (вычисленной на основании имени), то следующая запись каталога была удалена после нее. Например, запись config.dat была удалена раньше, чем readme.txt, потому что в противном случае длина записи config.dat была бы увеличена на 20 для поглощения места, занимаемого readme.txt. Следовательно, мы знаем, что файл config.dat был удален раньше readme.txt, allfiles.tar — раньше random.dat, a delete-files.sh — раньше sniffer.
Также можно заметить, что файл mytools.zip был удален после delete-files.sh, но до sniffer. Мы знаем это, потому что длина записи mytools.zip была увеличена до 44 для поглощения удаленной записи delete-files.sh. Если бы запись sniffer была удалена перед mytools.zip, то длина mytools.zip возросла бы с учетом этого факта. Также мы видим что файл passwords.txt был удален раньше sniffer, a random.dat — после

mytools.zip. Наконец, файл readme.txt был удален раньше sniffer, потому что длина записи readme.txt указывает на sniffer.
Потратив немного времени на определение относительного порядка удалений, мы приходим к выводу, что файлы удалялись в алфавитном порядке. Мы не знаем порядка удаления aLLfiLes.tar, config.dat и delete-files.sh, но зато нам известно, что они были удалены раньше других файлов, а в отсортированном списке имен эти файлы занимают первые три места. Следовательно, эти файлы могли быть удалены при отображении в окне отсортированного списка или же командой типа rm *. Команда rm удаляет файлы, и мои эксперименты показали, что удаление производится в алфавитном порядке. Скорее всего, файлы удалялись не один за одним, а из сценария или окна файлового менеджера. Если бы между удалениями создавались другие файлы, интерпретировать результаты было бы намного труднее. 
<< | >>
Источник: Кэрриэ Б.. Криминалистический анализ файловых систем. 2007

Еще по теме Категория данных имен файлов:

  1. Категория данных имен файлов
  2. Категория имен файлов
  3. Категория имен файлов
  4. Категория данных файловой системы
  5. Категория данных файловой системы
  6. Категория данных файловой системы
  7. Записи каталогов для длинных имен файлов
  8. Категория файловой системы
  9. Категории данных
  10. Методы анализа и категории данных
  11. Категория прикладных данных
  12. Категория данных содержимого
  13. Категория прикладных данных
  14. Категория прикладных данных
  15. Категория данных
  16. Конкретные файловые системы
  17. Шифрование файлов
  18. КАТЕГОРИИ ПРАКТИКИ И КАТЕГОРИИ АНАЛИЗА
  19. Что такое файловая система?
  20. Файловый хостинг