OSDev

А вы этим пользуетесь? Просто я предпочитаю YandexDesktop для поиска по содержимому файлов. Totalcomander для не индексируемых файлов.

По поводу последнего изменения думаю что нужно. А если много изменений, то нужен CVS.

Но вопрос был не в том. ФС я не планирую разрабатывать по крайней мере пока. Вопрос был в другом. С течением времени требуется вносить изменения. Так как я планирую что ОС будет поддерживать несколько ФС при этом одновременно. И могут добавляться и удаляться в процессе работы.

Типичный пример добавления это монтирование флешки. Или подключение сетевого диска. Или поверх NFTS реализовать CVS.
Такое подключение я ядре вызывает загрузку драйвера ФС. Драйвер ФС это DLL с реализацией интерфейса для заданной ФС.
Но что-бы соединить всё в месте мне нужен единый интерфейс. Который в дальнейшем предлагаю именовать виртуальная файловая система(ВФС).
Так вот вопрос как оптимально поступить с атрибутами. Я предполагаю что будут расширения от версии к версии ВФС. А также нужны будут разные атрибуты к разным ФС.

Т.е. т.е в ВФС дескриптор файла должен состоять из нескольких интерфейсов. Но как тут верно заметели большое число атрибутов надо генерировать и поддерживать. В никсах это решается сжатием путем 1 бит один атрибут. Тем самым структуры маленькие.

Что я хочу? Я хочу заложить подход к проектированию. В который можно расширять интерфейс без создания лишних костылей. И без надобности выяснять нужные что тут работает, а что нет.

Список атрибутов которые планирую взять основными приведу позже.

Так нету вроде такой возможности. А искать надо не по содержимому файла, а именно по тегам, которые пользователь сам собственноручно добавил к файлам.



Универсализма на уровне списка атрибутов не достичь хотя бы потому, что надо поддерживать не только "единственно правильную ФС", но и кучу других ФС, которые имеют разные наборы атрибутов, разные возможности и т.д. Мне кажется, что единственный реальный путь -- это делать системные сервисы обычных операций ввода-вывода (открытие, закрытие, чтение, запись, получение/установка позиции файла) и сервисы для получения/установки атрибутов. Последние принимают параметры некоего общего вида, а что с этими параметрами делать, решает уже драйвер конкретной файловой системы. Естественно, и управлять этими атрибутами совершенно "общим" способом, одинаково годящимся для любых ФС, не получится (в силу разницы в самих ФС). Можно разве что ввести список "стандартных" атрибутов (которые встречаются во многих распространённых ФС) и кодировать их неким сжатым образом (битовая маска, содержащая флаги типа "скрытый", "только для чтения" и т.д.), а всё остальное задавать в каком-нибудь более громоздком, но более-менее универсальном для разбора виде вроде "ключ=значение" (в текстовом виде). Хотя над этим вопросом как-то особо не задумывался, честно говоря.

После того, как я случайно удалил "защищённый" таким образом важный файл, я понял, что это - никудышняя защита. Надо делать резервные копии. А в свете их наличия атрибут становится совсем бесполезен. К тому же, в ряде ситуаций он просто не работает. Если же нужно действительно защитить файл от удаления и изменения, то для этого должна быть реализована система прав доступа (в её необходимости нет ни малейшего сомнения). Так же может быть решён и вопрос "видимости" файлов/папок.


Тут есть идеологический недочёт. По моей практике любая директория, в которой какому-то софту позволяется самостоятельно что-то писать, обязательно превратится в свалку, будь то проекты Visual Studio, домашний каталог в *никсах (а ведь было время, когда он был чистенький и кроме .profile там ничего лишнего не было) или домашний каталог в Винде, который и без скрытых файлов представляет собой помойное ведро. Атрибут "скрытый" в данном случае просто не спасает.
Я думаю, что для решения этой проблемы должно быть соглашение совсем другого рода, например, все конфигурационные файлы любой софт должен хранить в поддиректории .ini домашнего каталога, а в обозревателях файлов должна быть возможность указать (возможно по шаблону), какие именно файлы/папки не показывать. Тут дело вот в чём. Атрибут - это глобальное свойство, распространяющееся на все приложения и предназначенное для решения разных задач. А в данном случае этот атрибут оказывается нужен только для сокрытия при просмотре в проводнике. Так пусть проводник сам решает свою задачу. Например, в тотал-коммандере есть такая настройка и я ей действительно пользуюсь.


Согласен, вещь полезная. Однако, не вижу простого решения при помощи атрибутов.

_________________
Yet Other Developer of Architecture.
The mistery of Yoda’s speech uncovered is:
Just an old Forth programmer Yoda was.
<<< OS Boot Tools. >>>

На самом деле такая работа проделана, поскольку приведенный мной список атрибутов взят из MSDN, то есть соответствует виндовой IFS. Если 16-ти атрибутов будет недостаточно, под поле атрибутов файловой подсистемы можно зарезервировать 32 бита и закрыть тему.

Аналогично со временем создания/изменения/доступа. Раз эти атрибуты есть в существующих ФС, файловая подсистема ОС должна их штатно поддерживать. Можно, конечно, делать вид, что это забота драйвера конкретного программиста, но задача от этого не решится, а только усугубится. Для гибкости достаточно предусмотреть значение null для любого из времен, чтобы можно было штатно игнорировать его, когда в конкретной ФС соответствующего поля нет.

Проблема атрибутов не в том, что их много а в том, что набор слабо пересекается между файловыми системами. Самый продвинутый - как всегда в винде. Концепция файловых потоков из которых один - с данными очень хорошая и правильная. Такой подход позволяет создать из файловой системы универсальный фреймворк, который можно адаптировать для хранения любых данных и атрибутов совместимо с любой файловой системой даже ещё не созданной. К сожалению в ReFS микрософт от этой концепции похоже отказался или скажем так: она видоизменилась и теперь имеет значительные ограничения - только ассоциированный с файлом массив значений key-value.

Много читал и думал над концепцией тегов. Похоже вопрос не имеет нормального решения. Основная проблема "Кто будет присваивать тэги?". Пользователь быстро забьёт на это. Софт файловой системы? Писать софт, который будет присваивать тэги по фильмам? А потом по музыке? Это не вопрос файловой системы! Файловая системя для тэгов - это фреймворк, который позволяет строить альтернативные иерархии данных по тэгам и нормальный интерфейс к этому. Работы много а большого интереса не вызовет т.к. к новому интерфейсу привязыватся никто не захочет. Как это будет выглядеть для пользователей? Опять - новый интерфейс!