Предварительный взгляд на возможности файловой системы Protogon

Новая файловая система Protogon будет присутствовать в новой операционной системе Windows 8. Protogon находится на ранней стадии разработки. Позже было объявлено, что название файловой системы было изменено на ReFS (Resilient File System), и присутствовать она будет только в серверной версии Windows 8. Я проверил, какими возможностями обладает эта файловая система на сегодняшний день, используя образ Windows 8 build 6.2.7955 x86.

Сначала я отформатировал том в файловую систему Protogon:

C:\Windows\system32>format F: /FS:protogon /Q
The type of the file system is FAT32.
The new file system is PROTOGON.
Enter current volume label for drive F: NEW
WARNING, ALL DATA ON NON-REMOVABLE DISK DRIVE F: WILL BE LOST!
Proceed with Format (Y/N)? Y
QuickFormatting 20477M
Volume label (32 characters, ENTER for none)? NEW
Creating file system structures.
PROCESSOR DOES NOT SUPPORT HARDWARE CRC INSTRUCTION
Format complete.
      20.0 GB total disk space.
      20.0 GB are available.
Please be advised that the underlying format may be
incompatible with near-future versions.

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

F:\>fsutil fsinfo volumeinfo F:
Volume Name : NEW
Volume Serial Number : 0x4239b488
Max Component Length : 255
File System Name : Protogon
Is ReadWrite
Supports Case-sensitive filenames
Preserves Case of filenames
Supports Unicode in filenames
Preserves & Enforces ACL's
Supports Reparse Points
Supports Open By FileID
Supports USN Journal

Список пока небольшой, меньше чем у NTFS. Файловая система Protogon на сегодняшний день поддерживает точки повторной обработки (reparse points), открытие файла по идентификатору, журнал USN. Все эти возможности есть в NTFS.

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

F:\>echo a > file:stream
The request is not supported.

Зато драйвер файловой системы распознаёт имена стандартных атрибутов, которые были в NTFS. Как это определить? Вот, например, можно обратиться к основному содержимому файла, используя атрибут ::$DATA, точно так же, как в NTFS (данная операция производит запись символа b в файл):

F:\>echo b > file::$DATA

Произвести запись в файловый поток с таким синтаксисом тоже нельзя:

F:\>echo a > file:stream:$DATA
The request is not supported.

Распознаёт ли драйвер другие имена атрибутов NTFS? Да, драйвер их знает (но это не говорит о том, что он их обязательно использует).

Драйвер блокирует запросы к стандартным атрибутам NTFS, например если обращаться к стандартным именам $EA, $ATTRIBUTE_LIST и подобным, то реакция системы такая:

F:\>echo a > file::$EA
Access is denied.
F:\>more 
А если обратиться к атрибуту с таким именем, которого в NTFS нет, то сообщение системы будет другое:

F:\>more 
Делаю вывод, что драйвер файловой системы Protogon по крайней мере частично основан на коде драйвера NTFS, так как драйвер «знает»
имена внутренних атрибутов NTFS.






С помощью программы NTFS Stream Explorer я проверил возможность создания в файловой системе Protogon точки повторной обработки.
Я создал точку с произвольным идентификатором и GUID, а внутри поместил содержимое одного из конфигурационных файлов (он подходил
по размеру, так как точка повторной обработки обязана быть меньше 16 Кб). Создание прошло успешно. Утилита fsutil распознала
созданную точку повторной обработки и правильно прочитала информацию из неё:

F:\>fsutil reparsepoint query file
Reparse Tag Value : 0x0000a590
GUID : {F7108BD4-6B1B-46BB-9225-AD521E587EB3}
Reparse Data Length: 0x00000040
Reparse Data:
0000:  5b 69 6e 74 65 72 66 61  63 65 5d 0d 0a 6c 61 6e  [interface]..lan
0010:  67 75 61 67 65 3d 72 75  0d 0a 0d 0a 5b 66 69 6c  guage=ru....[fil
0020:  65 73 5d 0d 0a 6c 61 73  74 3d 46 3a 5c 66 69 6c  es]..last=F:\fil
0030:  65 0d 0a 73 61 76 65 5f  6c 61 73 74 3d 31 0d 0a  e..save_last=1..

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

F:\>mklink /D link_dir dir
symbolic link created for link_dir > dir
F:\>mklink link_file file
symbolic link created for link_file > file

Заодно проверил и возможность создания жёстких ссылок и точек монтирования (связей, junction). Команда mklink справилась только
с созданием символьной ссылки. 

F:\>mklink /J link_junc dir
Local NTFS volumes are required to complete the operation.
F:\>mklink /H link_h dir
Local NTFS volumes are required to complete the operation.

Да, mklink не смогла создать ссылку типа «junction». Однако, такая ссылка это всего лишь ещё одна разновидность точки повторной обработки,
а значит, должна поддерживаться. Я создал такую ссылку, используя свою программу 
NTFS Stream Explorer версии 2.00 (которая ещё в стадии beta).
Полученная связь («junction») нормально распознавалась проводником Windows.

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

По теме NTFS также есть следующее:

• Специальные файлы NTFS. О файлах типа $Volume, $MFT и подобных.
• Обход ограничений FAT32/NTFS (статья 2004 года).
• Использование NtFsControlFile для получение информации о файле на NTFS