Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 56
Имхо нет.
Максимум что можно выжать — наподобие Adobe Bridge — семантическое представление информации (т.е. просто индексированный поиск с «умными» фильтрами/папками). Текущая система имхо проста и удобна, а все недостатки надуманны.
Максимум что можно выжать — наподобие Adobe Bridge — семантическое представление информации (т.е. просто индексированный поиск с «умными» фильтрами/папками). Текущая система имхо проста и удобна, а все недостатки надуманны.
Причина кроется в самой сути — каждая папка или файл может иметь только одного родителя, связи между ними являются достаточно жесткими.Для большинства файловых систем это утверждение неверно. Так что Вы немного заблуждаетесь в самой этой сути. Раз уж Вы говорите о linux, то та самая ext2/3/4 — как раз граф, а не дерево. И, разумеется, все эти ФС
позволяет разместить файл/папку одновременно в нескольких папках
Симлинк?
Причём тут симлинк? Симлинк не создаёт прямых связей в ФС и нельзя сделать одному файлу двух родителей через симлинк. Может, вы имели ввиду т. н. hardlink?
Тем не менее через симлинк вы можете открыть файл из любой из двух папок. Зачем нужны жесткие связи в приведенном примере с фильмами — мне непонятно. Я вообще предпочитаю тэги для коллекций фильмов — это же удобнее, чем папки. Имею в виду специфический софт для коллекций, позволяющий тэги.
я думал о тегах. Но у них есть проблема — они обеспечивают «плоское отображение». А мне часто нужна иерархия.
А с моей точки зрения тэги от графов не сильно отличаются… Ну разве что вложенных тэгов не бывает (т.е. тэги не имеют родителей), но зато могут быть категории тэгов (по сути — уже тэги с родителем)… Скажем так: тэги и графы «рядом ходят».
Уж не знаю, как там в Ubuntu с Ext4, но это всегда можно было сделать так:
mv ./file1 ./folder1Теперь у одного и того же файла два родителя, совершенно равноценных. Или мы о чём-то другом говорим?
ln ./folder1/file1 ./folder2/file1
эээ, ну помоему 2 родителя не у файла, а у файла и у ссылки на него. я конечно не знаю на 100% как там в ext се устроено, но ведь эти вещи все-таки назвали *ссылками*, а не как-то по-другому?
То есть нужны шашечки, а не ехать?
нет. тогда уж 2 родителя у 2-х ссылок на файл: по 1-му родителю на каждую ссылку. ln без параметров — это хардлинк, полученная ссылка равноправна с исходной.
Итак, повторяем основы. Ссылка — это привязка файла к родительскому каталогу и ничего другого. Файл лежит в каталоге — есть одна ссылка. Делаем вторую ссылку — теперь файл в двух каталогах, эти две ссылки отныне никак не отличаются. Удаляем одну ссылку — файл остаётся существовать (ибо есть одна ссылка), удаляем вторую ссылку — файл пропадает из поля зрения, ибо ссылок на него больше нет. Для каждого файла ведётся учёт количества ссылок, когда их ноль — файл зачищается.
Я не совсем правильно выразился. Я хочу создать надстройку над ФС, которая позволит манипулировать файлами, папками и связями на более высоком уровне. Можно написать скрипт на страницу, который будет искать в файле нужное, а можно использовать БД. Примерно такая аналогия.
и граф для пользователя, а не для кишок ФС, про которые конечный пользователь не знает и знать не должен.
Видели nepomuk.kde.org/?
Я считаю, что стоит. Каждый проект, который имеет хоть какие-нибудь шансы стать полезным, стоит реализовывать. Ибо даже самые безумные идеи сегодня могут стать необходимыми завтра. Да и для саморазвития хорошо.
ЕМНИП, попытка создать такую ФС оказалась фатальной для проекта LongHorn :)
А идея библиотек в Win7 не то же самое?
Автор, поменяйте название на «Еще одно средство индексирования»
ну, знаете, я очень люблю самому создавать структуру. на маках из-за этого мне скучно… не могу сделать так как мне нужно
> По-моему, это всего лишь удобно для пользователя присвоить какие-то жесткие рамки хранению файлов на своём компе.
+1. имхо, для практического применения пользователем достаточно все файлы хранить в одном каталоге (или их иерархии, например по дате/типу/етц, невидимой конечному пользователю) и оперировать только тэгами.
+1. имхо, для практического применения пользователем достаточно все файлы хранить в одном каталоге (или их иерархии, например по дате/типу/етц, невидимой конечному пользователю) и оперировать только тэгами.
Не так давно тоже задумался над темой семантических ФС. Если кому-то будет интересно, можете ознакомиться с моим концептом (очень драфт).
Я бы к вашему описанию добавил, что SmartTag'и должны быть определены либо в виде скриптов, либо за них должны отвечать какие-то приложения (как системные, так и сторонние), тогда, глядишь, не будет проблем с тем, что приложение прочитает файл «злоумышленника». Ну и при переноске файлов на внешних носителях нужно для SmartTag'ов hash какой-то передавать или что-то в этом роде, а когда файл «возвращается в систему» с внешнего носителя — скрипт или приложение уже должно по структуре определить что можно с этим файлом делать, а что нельзя.
Если скрипты, то главная фича — возможность создавать любые свои SmartTag'и. Вот уж тут раздолье для программистов будет.
А имя файла я бы хранил не как Tag, а как атрибут какого-нибудь SmartTag'а «name» (иначе база тэгов очень быстро переполнится сразу после установки ОС, и тормозить все это будет ой-ей).
А имя файла я бы хранил не как Tag, а как атрибут какого-нибудь SmartTag'а «name» (иначе база тэгов очень быстро переполнится сразу после установки ОС, и тормозить все это будет ой-ей).
В идее записывать алгоритм вычисления атрибутов SmartTag'ов в виде скриптов мне видятся следующие недостатки:
1) низкая производительность (ведь скрипты может написать любой человек, незнакомый с оптимизацией);
2) небезопасность;
3) возможность зацикливания при вычислении атрибутов.
Вообще-то, все эти же недостатки в какой-то мере присущи и SmartTag'ам, записанным на низкоуровневых языках или машинных инструкциях. Что с этим делать — пока непонятно.
Имя файла лучше всё же хранить как тег, поскольку так мы сможем построить индекс по именам. Работать должно быстро. Если же это будет вычислимое свойство смарт-тега, то при каждом поиске файла надо будет пробегаться по всем файлам в системе и спрашивать у них атрибут name.
1) низкая производительность (ведь скрипты может написать любой человек, незнакомый с оптимизацией);
2) небезопасность;
3) возможность зацикливания при вычислении атрибутов.
Вообще-то, все эти же недостатки в какой-то мере присущи и SmartTag'ам, записанным на низкоуровневых языках или машинных инструкциях. Что с этим делать — пока непонятно.
Имя файла лучше всё же хранить как тег, поскольку так мы сможем построить индекс по именам. Работать должно быстро. Если же это будет вычислимое свойство смарт-тега, то при каждом поиске файла надо будет пробегаться по всем файлам в системе и спрашивать у них атрибут name.
1) Согласен насчет производительности, но «коли не умеешь, то не лезь». Эта возможность больше для сведущих. Сами по себе скрипты должны быть прекомпилируемыми.
2) Только с правами администратора их можно править.
Вообще этим скриптам можно давать предельное время выполнения — если привысил, то, допустим, убивается. Если постоянно превышает, то считается «плохим». Но это уже детали.
«Если же это будет вычислимое свойство смарт-тега, то при каждом поиске файла надо будет пробегаться по всем файлам в системе и спрашивать у них атрибут name».
Вовсе необязательно. Если смарт-тег — это, по сути, небольшая утилита, то можно обратиться напрямую к смарт-тегу и запросить у него файлы с указанным атрибутом, внутри себя смарт-тег также обратится к БД, которая сделает быструю выборку.
2) Только с правами администратора их можно править.
Вообще этим скриптам можно давать предельное время выполнения — если привысил, то, допустим, убивается. Если постоянно превышает, то считается «плохим». Но это уже детали.
«Если же это будет вычислимое свойство смарт-тега, то при каждом поиске файла надо будет пробегаться по всем файлам в системе и спрашивать у них атрибут name».
Вовсе необязательно. Если смарт-тег — это, по сути, небольшая утилита, то можно обратиться напрямую к смарт-тегу и запросить у него файлы с указанным атрибутом, внутри себя смарт-тег также обратится к БД, которая сделает быструю выборку.
Со всем согласен, но не пойму, каким образом ФС найдёт смарт-тег, способный вычислить имена файлов, если сам он является безымянным, и для вычисления своего имени должен обратиться к себе же? =) Или сделать его системным и неизменяемым, чтобы в недрах ФС хранилась ссылка на его дескриптор? Можно, но стоит ли это того? Какой профит?
К тому же, этот смарт-тег будет хранить и индексировать имена файлов в БД точно так же, как и в случае с жёстко зашитыми именами тегов, так что вряд ли это будет быстрее.
И последнее: мне не совсем ясно, как будут выглядеть поисковые запросы на уровне консоли? В моём концепте всё прозрачно:
«select X» — выбрать все файлы с именем «X»;
«select [Y]» — выбрать файлы с тегом «Y»;
«select X[Y[Z]]» — выбрать файлы с именем «X», тегом «Y», который помечен тегом «Z».
Мне кажется, такая запись проста и интуитивно понятна. А как будут выглядеть эти же запросы, если их переписать с использованием вычислимых свойств?
К тому же, этот смарт-тег будет хранить и индексировать имена файлов в БД точно так же, как и в случае с жёстко зашитыми именами тегов, так что вряд ли это будет быстрее.
И последнее: мне не совсем ясно, как будут выглядеть поисковые запросы на уровне консоли? В моём концепте всё прозрачно:
«select X» — выбрать все файлы с именем «X»;
«select [Y]» — выбрать файлы с тегом «Y»;
«select X[Y[Z]]» — выбрать файлы с именем «X», тегом «Y», который помечен тегом «Z».
Мне кажется, такая запись проста и интуитивно понятна. А как будут выглядеть эти же запросы, если их переписать с использованием вычислимых свойств?
В качестве «командной строки» нужна возможность использовать некое подобие SQL-запросов (ну или чего-то близкого), хотя бы как «запасной вариант».
но он не является достаточно практичным для простого пользователя. Раскройте эту мысль, пожалуйста.
Давно думал над чем то в таком духе. Только в том, что я думал, были не папки, а теги.
К примеру — я открываю файловый менеджер. Выбираю тип файла(музыка, видео, документы, картинки). Потом выбираю нужный тег/ввожу его. Например выбираю «картинки» и «дерево» — показывается куча деревьев. Добавляю тег «человек» — показываются люди с деревьями. И т.д.
При сохранении файла — никаких папок вообще нет. Просто указыватся теги по которым я бы потом хотел этот файл находить. Добавить так же автоматические теги, создающиеся на основе даты, имени пользователя. В случае документов можно сделать что то типа тегов на основе содержания, и вынести их в отдельный список.
Основной недостаток моего подхода — нужно менять все окружение пользователя. Что, конечно, реально, но очень долго.
В вашем же варианте недостаток в том, что фактически тот же функционал можно реализовать банально симлинками.
К примеру — я открываю файловый менеджер. Выбираю тип файла(музыка, видео, документы, картинки). Потом выбираю нужный тег/ввожу его. Например выбираю «картинки» и «дерево» — показывается куча деревьев. Добавляю тег «человек» — показываются люди с деревьями. И т.д.
При сохранении файла — никаких папок вообще нет. Просто указыватся теги по которым я бы потом хотел этот файл находить. Добавить так же автоматические теги, создающиеся на основе даты, имени пользователя. В случае документов можно сделать что то типа тегов на основе содержания, и вынести их в отдельный список.
Основной недостаток моего подхода — нужно менять все окружение пользователя. Что, конечно, реально, но очень долго.
В вашем же варианте недостаток в том, что фактически тот же функционал можно реализовать банально симлинками.
Многие об этом думали. Только пока это не будет удобно реализовано в ОС, причем так, чтобы из любого приложения эти тэги работали, ничего путного не выйдет.
Зато если такая ОС появится, то это может быть революцией в работе с файлами на компьютере.
Если Google Chrome OS даст возможность тэггировать данные, которые будут храниться в облаке — это будет первая подобная ОС (если не прав насчет «первости» — поправьте). Хотя я бы предпочел обычную, не «удаленную» ОС.
Зато если такая ОС появится, то это может быть революцией в работе с файлами на компьютере.
Если Google Chrome OS даст возможность тэггировать данные, которые будут храниться в облаке — это будет первая подобная ОС (если не прав насчет «первости» — поправьте). Хотя я бы предпочел обычную, не «удаленную» ОС.
Не обязательно всё и сразу, так точно ничего не выйдет. Вполне можно на основе тегов создавать иерархическую структуру с симлинками — в результате приложения, которые работу с тегами пока что не поддерживают, смогут вполне достойно функционировать.
Но, да, безусловно — нужна поддержка на уровне ОС. В убунте какой нибудь можно попробовать реализовать, они любят всякие извращения в дистрибутив протаскивать ^^
Но, да, безусловно — нужна поддержка на уровне ОС. В убунте какой нибудь можно попробовать реализовать, они любят всякие извращения в дистрибутив протаскивать ^^
Ну такие же вопросы возникают походу у многих. Вот например различные ссылки по теме.
[http://habrahabr.ru/blogs/linux/90326/ Правильная организация файлов или наше спасение в наших руках]
[http://habrahabr.ru/blogs/i_am_insane/68092/ Файловые системы — отстой!]
[http://tanner.habrahabr.ru/blog/90333/ Как Вы организуете поиск и хранение информации на своём жёстком диске/медиасервере/NAS?]
[http://rm.pp.ru/info/mhddfs mhddfs: объединение нескольких файловых систем в одну большую виртуальную]
[http://habrahabr.ru/blogs/development/81352/ Как сделать теговую ФС удобной для пользования]
[http://amarao-san.livejournal.com/1693391.html tagfs — примерная спецификация]
[http://demitsuri.habrahabr.ru/blog/40791/ Построение иерархических классификаторов на основе тщательно спроектированной системы тегов]
[http://habrahabr.ru/blogs/i_am_clever/40679/ Все под рукой или как организовать информацию (Хабр)]
[http://www.claris-verbis.ru/organizing_information Все под рукой или как организовать информацию]
[http://habrahabr.ru/blogs/linux/90326/ Правильная организация файлов или наше спасение в наших руках]
[http://habrahabr.ru/blogs/i_am_insane/68092/ Файловые системы — отстой!]
[http://tanner.habrahabr.ru/blog/90333/ Как Вы организуете поиск и хранение информации на своём жёстком диске/медиасервере/NAS?]
[http://rm.pp.ru/info/mhddfs mhddfs: объединение нескольких файловых систем в одну большую виртуальную]
[http://habrahabr.ru/blogs/development/81352/ Как сделать теговую ФС удобной для пользования]
[http://amarao-san.livejournal.com/1693391.html tagfs — примерная спецификация]
[http://demitsuri.habrahabr.ru/blog/40791/ Построение иерархических классификаторов на основе тщательно спроектированной системы тегов]
[http://habrahabr.ru/blogs/i_am_clever/40679/ Все под рукой или как организовать информацию (Хабр)]
[http://www.claris-verbis.ru/organizing_information Все под рукой или как организовать информацию]
Тьфу ты, отослалось по ошибке.
Правильная организация файлов или наше спасение в наших руках
Файловые системы — отстой!
Как Вы организуете поиск и хранение информации на своём жёстком диске/медиасервере/NAS?
mhddfs: объединение нескольких файловых систем в одну большую виртуальную
Как сделать теговую ФС удобной для пользования
tagfs — примерная спецификация
Построение иерархических классификаторов на основе тщательно спроектированной системы тегов
Все под рукой или как организовать информацию (Хабр)
Все под рукой или как организовать информацию
Организация данных на локальной машине. Мечты.
Ну есть еще всякие задумки в виде заметков набросок. Для фильмов даже набросал небольшую виртуальную файловую систему на C#+Mono+MySQL+FUSE.
А так симлинки вещь неплохая, можно например писать скрипты для создания симлинков(хардлинков), делал когда то небольшой реп с софтом, так для разных категорий как раз симлинками прописывал чтобы можно было нормально через фтп бегать.
Nepomuk интересная вещь, и возможно когда то он как раз и сделает то что мы всем хотим. Но лично для меня он пока менее юзабилен чем самописные скрипты и системы под частные случаи.
Правильная организация файлов или наше спасение в наших руках
Файловые системы — отстой!
Как Вы организуете поиск и хранение информации на своём жёстком диске/медиасервере/NAS?
mhddfs: объединение нескольких файловых систем в одну большую виртуальную
Как сделать теговую ФС удобной для пользования
tagfs — примерная спецификация
Построение иерархических классификаторов на основе тщательно спроектированной системы тегов
Все под рукой или как организовать информацию (Хабр)
Все под рукой или как организовать информацию
Организация данных на локальной машине. Мечты.
Ну есть еще всякие задумки в виде заметков набросок. Для фильмов даже набросал небольшую виртуальную файловую систему на C#+Mono+MySQL+FUSE.
А так симлинки вещь неплохая, можно например писать скрипты для создания симлинков(хардлинков), делал когда то небольшой реп с софтом, так для разных категорий как раз симлинками прописывал чтобы можно было нормально через фтп бегать.
Nepomuk интересная вещь, и возможно когда то он как раз и сделает то что мы всем хотим. Но лично для меня он пока менее юзабилен чем самописные скрипты и системы под частные случаи.
кстати, сдается мне, что то что хочет ТС можно с минимальными усилиями сделать на основе Reiser4. либо, написать плагин к ReiserFS 4.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Семантическая файловая система