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

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

Вот напишешь свою ОСь, там и запилишь все свои неосиляторские мыслишки и прочий белый шум.

не лучше ли было сделать их тоже файлами

И для этих файлов тоже нужны файлы атрибутов, для которых тоже нужны файлы атрибутов, для которых… Ну ты понял.

Зачем тебе атрибуты для атрибутов? У тебя их и так нету, и тут не будет.

Будет

$ cat file.txt:created_at:created_at 
Нет такого файла или каталога

Ну если это тоже файлы, то для них тоже нужны атрибуты, нет? Права доступа там и всё такое прочее.

Нет такого файла или каталога

Тогда это уже не файл.

Ты почему-то думаешь, что в юниксе действует принцип «всё есть файл». На самом деле этот принцип в юниксе не действует. В Plan 9 такой принцип действительно есть и там действительно атрибуты файла можно читать из файлов.

Файлы разные бывают, у этих не будет атрибутов, ну или можно сделать симлинк на ту же директорию с атрибутами, рекурсия!

Нет такого файла или каталога

Тогда это уже не файл.

А в Linux можно удалить корень, это же файл?

Есть ссылка на plan9 документацию как это сделано?

Так напиши свой Шелл со своими утилитами и особым синтаксисом. Для этого нафиг не нужно «делать файл директорией».

Всё есть файл уже не модно. Хочешь на волну хайпа и мейнстрима — всё есть файловая система.

И как мне из других программ открыть file.txt:created_at? Лучше тогда свой драйвер fuse.

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

Записать дату создания echo **** > file.txt:created_at

А для человеков такое надо раз в год.

Из каких «других программ»? Другие программы уже написаны, и их авторы осилили атрибуты файлов.

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

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

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

Потому что:

1. UNIX это не Plan9
2. Даже в Plan9 такого не было, хотя и многое было сделано по пути на встречу идее «всё есть файл»

Ну делай, кто мешает. Реализовать легко. Сложно заставить это юзать и сохранить совместимость.

С чего ты решил, что виртуальные файлы «бесплатные»? Если атрибут тоже файл, значит надо для него создавать inode в vfs.

Здесь нужно лицо Икзибита: «Ты теперь можешь менять атрибуты у атрибутов!»

Можно создавать только те, за которые платишь.

Знаешь, я всё же поддержу предыдущего оратора Почему в UNIX атрибуты файлов не являются файлами? (комментарий)

Фишка в том, что многие вещи не очевидны до тех пор, пока не начнёшь писать код. Так что можешь попробовать написать свой драйвер фс и увидеть на практике что да как.

сделать их тоже файлами, а сам файл директорией

Если атрибуты будут файлами, то что будет атрибутами этих файлов? Как в анекдоте «там дальше вниз идут одни черепахи».

Я про чтение с диска говорил.

Выше описал.

Еще нужно, чтобы название файла тоже было отдельным файлом.

Через это можно реализовать rename, так что идея не такая уж и глупая.

Ну так вперёд и с песней, пили, компиляй.

Я лучше посмотрю, давай ты, жду ссылку на репозиторий.

Быстрее обратиться к полю структуры и получить данные, чем читать с диска.

Так все равно эта «структура» где-то на диске хранится, почему быстрее? Может наоборот было бы быстрее если атрибуты и «контент» хранить отдельно - читаешь\пишешь только нужные данные.

проще и быстрее в целях реализации

Ну тут не поспоришь

Так все равно эта «структура» где-то на диске хранится, почему быстрее? Может наоборот было бы быстрее если атрибуты и «контент» хранить отдельно - читаешь\пишешь только нужные данные.

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

Записать дату создания echo **** > file.txt:created_at

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

Так я понимаю, что проще либо разобраться с «зоопарком утилитных опций», либо самому что-то написать на сишке (такого ещё не было), чем городить песочный замок.

Так все равно эта «структура» где-то на диске хранится, почему быстрее?

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

Может наоборот было бы быстрее если атрибуты и «контент» хранить отдельно - читаешь\пишешь только нужные данные.

А если у тебя 10 потоков, а 100?

Я, например, хочу знать, когда файл был создан, а не когда какой-то Васян захотел, чтобы он был создан.

Тут и сейчас никто не мешает Васяну сделать cp 1.txt 2.txt rm 1.txt mv 2.txt 1.txt. И ты также узнаешь только время которое тебе захотел Васян показать.

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

Это уже не тот минимализм, просто интересная задумка.

На самом деле ничего не мешает это и сейчас сделать написав небольшой ядерный модуль и ловить обращение куда-нить

ls -al /sys/ext/real_path/*
cat /sys/ext/home/vasyn/my_file/create_date
echo `date` > /sys/ext/home/vasyn/my_file/create_date

для атрибутов модуль будет совсем-совсем маленький

Хорошая идея с отдельной директорией под атрибуты, так не надо создавать два потомка у папки, но непонятно что делать если в директории my_file будет create_date

В чём проблема-то ? Это ж ядрённый модуль и что в конце это не реальный файлы, а просто point. Так что если там будет файл, то у него посмотреть атрибут будет

cat /sys/ext/home/vasyn/my_file/create_date/create_date

а на

cat /sys/ext/home/vasyn/my_file/create_date

вернётся дата создания файла/директории /home/vasyn/my_file

Во-первых, 1.txt тоже должен как-то появиться с произвольной датой. Во-вторых, авторский юзкес это типа будет шорткатом для последовательности команд?

Зачем тебе атрибуты для атрибутов? У тебя их и так нету, и тут не будет.

Потому что это теперь файлы, значит должны. Иначе будет unsound.

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

Хм, а данные то, простите, где? Если файл это нода дерева, аттрибуты - листья, то что же тогда данные, которые тоже таки где-то тут должны быть.

Это можно сделать написав модуль ядра предоставляющий соответствующий интерфейс в /sys/ или /proc/, а сам модуль уже будет иметь подсистемы для взаимодействия с файловой системой которая обрабатывает файл и поддерживает те или иные файловые атрибуты.

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

Так или иначе не вижу больших препятствий, сойдись пейши =)

сделать «:»

В Classic Mac OS в файловой системе помнится был именно такой разделитель путей:

• https://raw.githubusercontent.com/EXL/2048/refs/heads/master/image/MCW-MacOS-9_0-Screenshot.png
• https://raw.githubusercontent.com/EXL/2048/master/image/MCW-MacOS-8_1-Screenshot_2.png
• https://raw.githubusercontent.com/EXL/2048/master/image/MPW-MacOS-8_1-Screenshot.png

См. Path, Source и заголовки окон.

пусть это будет виртуальный файл, тогда разницы не будет

Кроме в 6 раз большего количества open/close? atime, mtime, uid, gid, attributes - что там еще?

чем обратиться к ячейке памяти

Эта ячейка памяти сейчас она где хранится? Если брать что-то мейнстримное, ext\xfs, оно разве не на диске рядом с файлом? Типа в таблице ФС записано что файл начинается с «адреса» 1234, первый байт это атрибуты, дальше само содержимое файла. То есть я не понимаю почему хранить атрибуты «в файле» проще (в контексте работы с атрибутами) чем хранить их отдельно?

А если у тебя 10 потоков, а 100?

В чем проблема?

все есть блокчейн

cp 1.txt 2.txt rm 1.txt mv 2.txt 1.txt

touch 1.txt Васян сделает

Выкинь ты этот древний подход «все есть файл»! Нужно делать «все есть объект! А у объекта есть свойства»

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