Почему в UNIX атрибуты файлов не являются файлами?

Нет, файл - это файл, набор байтов, с именем и атрибутами.

Файл - это объект, в котором может и не быть никаких байт (socket, dev, folder, и т.д.), у которого есть номер inode (имя это просто примитивное human ident и которое сильно не обязательно) и у которого есть некоторый набор свойств.

Ну ты уж слишком глубоко копнул :)

что бы не запутаться

по моему получится совершенно наоборот.

Интересное рассуждение в комментариях… С каких это пор ОС отвечает за атрибуты файлов? Это вопросы к ФС. Немного тут погуглил по теме. А с чего вдруг ФС отвечает за иерархию файлов? Это вопросы к ОС. ФС же не лезет разделами управлять и не решает вопросы, куда этот раздел подключить (примонтировать).

Файл это только данные. Атрибуты файлов это метки для ОС как использовать данный файл. В простейшем случае три правила для использования файла: записать, прочитать и выполнить как программу. Когда в системе не один пользователь, появляются их иерархия, пользователи объединяются в группы и добавляются соответствующие атрибуты. Эти атрибуты хранятся в индексном дескрипторе (inode). Имена файлов и их инодов хранятся в каталогах (правильное название папки и директории), которые также являются файлом (данные). Иноды это записи в логических блоках на диске. http://mydirectx.ru/administr/indeksirovanie_deskriptorov.htm Иными словами, атрибуты зарыты уровнем ниже самих файлов. Таким образом, атрибуты файлов «размазаные» по всем логическим блокам на диске. Вы же предлагаете вытащить их на уровень каталогов, то есть, в ограниченное число блоков. Что ожидать?

Объект это данные и метод их обработки. В Windows метод обработки вызывается по суффиксу у названия файла (данных).

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

У директории тоже есть права доступа. Если файл сделать директорией, то где держать её собственные права? Файл, в простейшем случае, представляет из себя массив данных и структуру дентри с именем и атрибутами. Так вот, структура дентри - она доступна не через сам файл, а через его родительский каталог. Все системные вызовы, которые принимают имя файла, работают с дентри. А вызов опен() позволяет получить дескриптор уже для доступа к массиву данных.

Вызовы типа fstat(), которые обращаются к дентри через дескриптор - это, скорее, костыль для удобства. А вот вызовы типа фстатат() - вполне логичны, так как обращаются к дентри через дескриптор родительского каталога.

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

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

Директория в моем предложении имеет два списка потомков, к одному обращение через /, к другому через :

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

Я вам задал другой вопрос: где хранить атрибуты того каталога, в который вы входите чтобы считать атрибуты файла?

И так, ещё раз. Был файл a.txt. Стало:

Каталог a.txt и в нём: a.txt:attrs и a.txt:data.

Где хранить атрибуты самого каталога a.txt?

Я вам задал другой вопрос: где хранить атрибуты того каталога, в который вы входите чтобы считать атрибуты файла?

Зачем их хранить? Пусть создаются при обращении на основе тех что уже есть у файла.

Не можешь записать в файл, не можешь и сделать touch через доступ к атрибутам файла.

Зачем их хранить? Пусть создаются при обращении на основе тех что уже есть у файла.

Я верно понял, что, в указанной выше иерархии, у вас a.txt:attrs - это атрибуты как a.txt:data, так и самого каталога a.txt? И, до кучи, ещё и самого a.txt:attrs?

file.txt:created_at

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

там тоже суть такая, присераешь к файлу через двоеточие что-то. и пиши-читай можно делать.

тред-детектор вантузоидов?

https://learn.microsoft.com/ru-ru/windows/win32/fileio/file-streams https://learn.microsoft.com/ru-ru/windows/win32/fileio/using-streams

издалека похоже на файловые потоки в винде для ntfs.

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

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

Забей. Линкус уже никому не интересен.)