Ранняя история файловых атрибутов Windows, и почему в них есть место между System и Directory

Это перевод The early history of Windows file attributes, and why there is a gap between System and Directory. Автор: Реймонд Чен.

Если вы посмотрите на значения основных файловых атрибутов Windows, то увидите, что значение 8 пропущено.

FILE_ATTRIBUTE_...	Значение
READONLY	$00000001
HIDDEN	$00000002
SYSTEM	$00000004
	$00000008
DIRECTORY	$00000010
ARCHIVE	$00000020

Заведите машину времени на времена CP/M.

CP/M поддерживала одиннадцать атрибутов:

Имя	Значение
F1, F2, F3, F4	Определяются пользователем
F5, F6, F7, F8	Определяются интерфейсом
T1	Read-only
T2	System
T3	Archive

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

Семантика определяемых интерфейсом атрибутов задавалась для каждого интерфейса ОС. Вы можете думать о них просто как о четырёх дополнительных флагах для системного вызова (syscall), принимающего блок управления файлом (file control block). Вы могли установить или сбросить атрибуты, определяемые интерфейсом, перед вызовом функции - таким образом, передав четыре дополнительных флага. Или же функция могла установить или сбросить эти атрибуты перед возвратом управления, вернув, таким образом, четыре флага. На диске эти атрибуты не хранились.

Бит Read-only помечает файл как доступный только для чтения.

Бит System имел два эффекта: во-первых, он скрывал файл из списка файлов каталога. Во-вторых, если файл принадлежал пользователю 0¹, то тогда файл был доступен для всех пользователей (это было удобно для файлов программы).

Бит Archive сообщал, была ли сделана резервная копия файла.

Эти атрибуты были внедрены в существующую структуру каталога путём использования старшего бита одиннадцати символов имени файла! Вот почему они называются F1-F8 (старшие биты восьмисимвольного имени файла) и T1-T3 (старшие биты трехсимвольного расширения, также называемого типом файла).

Из этого вы можете сделать вывод, что имена файлов CP/M были ограничены 7-разрядным ASCII.

В любом случае, MS-DOS 1.0 разделила двойное значение атрибута System на два атрибута (Hidden и System), и хотя она не реализовала атрибут Read-only, но место для него было зарезервировано.

Это объясняет, почему первыми тремя атрибутами стали Read-only (1), Hidden (2) и System (4).

Одно из важных изменений в MS-DOS 2.0: поддержка подкаталогов, но еще одна новая особенность - это метки томов. Поскольку в заголовке диска не было места для метки тома, метка тома была добавлена ​​как запись со специальным атрибутом в корневом каталоге².

Поэтому следующие по списку атрибуты - это Volume label (8), Directory (16) и Archive (32).

Win32 унаследовала те же значения атрибутов файлов, что и MS-DOS и 16-битная Windows - предположительно, в стремлении свести к минимуму неожиданности при переносе кода с 16 бит на 32 бита. Атрибут Volume label исчез из Win32, но бит для каталога и архива был оставлен с их исходными значениями, чтобы избежать проблем с программами, которые работают с атрибутами файлов. Эти программы содержали свои собственные определения атрибутов файлов, поскольку 16-разрядная Windows не предоставляла своих.

¹ CP/M поддерживала до 16 пользователей с номерами от 0 до 15. Когда вы запускали компьютер, вы становились пользователем 0, но вы могли изменить текущего пользователя командой USER n. Файлы, принадлежащие другим пользователям, были недоступны вам, за исключением тех файлов, которые принадлежали пользователю 0 и были помечены атрибутом System. В любой момент любой пользователь мог переключиться на любого другого пользователя, так что это была функция организации файлов, а не функция безопасности. На практике никто не использовал эту возможность, поскольку гибкие диски были настолько малы, что было проще организовать ваши файлы, поместив их на разные дискеты, а не пытаясь запомнить, какого пользователя вы использовали для каждого файла.

² Windows 95 позже назначила новый смысл атрибуту Volume label: им она пометила запись каталога для хранения длинных имён файлов. Причиной для этого решения стало то, что многие дисковые утилиты читали каталоги с диска напрямую, поэтому любое изменение в формате каталога на диске представляло собой риск совместимости. Выбор использования атрибута Volume lable для этой цели стал результатом большого количества экспериментов по поиску наименее разрушительное изменение формата файла для длинных имён файлов. Оказалось, что большинство низкоуровневых дисковых служебных программ игнорировали всё, что было отмечено атрибутом Volume label.