OSDev

для всех
Текущее время: 22 май 2018, 01:36

Часовой пояс: UTC + 3 часа




Начать новую тему Ответить на тему  [ Сообщений: 25 ]  На страницу Пред.  1, 2, 3
Автор Сообщение
 Заголовок сообщения: Re: Интерфейс возможно файловый.
СообщениеДобавлено: 15 апр 2015, 16:17 
Аватара пользователя

Зарегистрирован: 16 май 2007, 23:46
Сообщения: 1088
Цитата:
Вот что полезно было бы -- возможность привязать к файлам текстовые теги, заданные пользователем, чтобы потом быстро искать файлы именно по этим тегам.

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

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

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

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

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

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

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Интерфейс возможно файловый.
СообщениеДобавлено: 15 апр 2015, 18:18 

Зарегистрирован: 28 окт 2007, 18:33
Сообщения: 1344
Откуда: Зеленоград
pavia писал(а):
А вы этим пользуетесь? Просто я предпочитаю YandexDesktop для поиска по содержимому файлов. Totalcomander для не индексируемых файлов.


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

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


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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Интерфейс возможно файловый.
СообщениеДобавлено: 16 апр 2015, 00:07 
Аватара пользователя

Зарегистрирован: 14 мар 2011, 12:31
Сообщения: 944
Откуда: Дагоба
SII писал(а):
Я довольно широко использую атрибут "только для чтения" для своих собственных нужд -- чтобы случайно не похерить файл, который мне нужен и содержимое которого должно оставаться неизменным.

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

SII писал(а):
Атрибут скрытого файла тоже небесполезен -- позволяет не загромождать отображаемый каталог служебными файлами, которые должны там быть, но которые не нужны пользователю.

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

SII писал(а):
Вот что полезно было бы -- возможность привязать к файлам текстовые теги, заданные пользователем, чтобы потом быстро искать файлы именно по этим тегам.

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

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

<<< OS Boot Tools. >>>


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Интерфейс возможно файловый.
СообщениеДобавлено: 16 апр 2015, 08:31 
Аватара пользователя

Зарегистрирован: 28 май 2012, 23:44
Сообщения: 237
Откуда: Санкт-Петербург
SII писал(а):
Универсализма на уровне списка атрибутов не достичь хотя бы потому, что надо поддерживать не только "единственно правильную ФС", но и кучу других ФС, которые имеют разные наборы атрибутов, разные возможности и т.д.

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

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Интерфейс возможно файловый.
СообщениеДобавлено: 16 апр 2015, 12:17 
Аватара пользователя

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

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


Вернуться к началу
 Профиль  
 
Показать сообщения за:  Поле сортировки  
Начать новую тему Ответить на тему  [ Сообщений: 25 ]  На страницу Пред.  1, 2, 3

Часовой пояс: UTC + 3 часа


Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 1


Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете добавлять вложения

Найти:
Перейти:  
Создано на основе phpBB® Forum Software © phpBB Group
Русская поддержка phpBB