о файловой системе

[avva]

Ну хорошо. Может она, иерархическая файловая система то есть, действительно не нужна?

Все эти каталоги в каталогах. Широченное дерево, ползучее. Кто сказал, что именно так должно быть?

Вот в последнее время так популярно стало вместо иерархии делать метки. Вместо иерархического дерева закладок - del.icio.us, с тагами на каждом URLе. Вместо иерархического дерева фотоальбомов - Flickr с тагами на каждой картинке. И так далее.

Давайте скажем: нет никакой иерархической файловой системы. Есть файлы. У каждого файла есть набор меток. В некоторых случаях эти метки хранятся вместе с самим файлом, в некоторых - отражают то, где он хранится ("cd").

Если у файла есть метка "program", его можно запустить. Конфигурационные файлы помечены "config", а конфигурационные файлы системы имеют метки "config" и "system" одновременно. Плюс метку определённого пакета или модуля, в случае надобности.

Директорий нет. Вместо понятия текущей директории есть понятие текущего набора меток, который включает в себя те метки, что я хочу видеть, и, возможно, какие-то, которых не хочу (так файлы "system" будут скрыты от обычного пользователя). Вместо команд "dir" и "ls" есть команда, которая показывает все файлы, отвечающие текущему набору меток. Если у компьютера есть несколько пользователей, файлы каждого помечены меткой его username. Вместо команды "cd" есть команда, меняющая текущий набор меток. Графические программы для работы с файлами делают понятие текущего набора меток наглядным и легко изменяемым.

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

"Копировать файл" означает клонировать его и изменить какую-нибудь существенную метку (или добавить). Например: я программист и у меня есть проект foo, в котором 100 файлов. Я хочу сделать новую копию всего проекта и работать над ней. Создаю новую существенную метку current и клонирую весь проект в неё. Аналогом переноса файла из одного каталога в другой теперь является изменение набора существенных меток (без клонирования). Записать набор файлов на USB-диск означает выделить нужный набор файлов и склонировать их с меткой usb.

Не будет работать? Слишком сложно? Слишком неинтуитивно?

Comments

[bolk.livejournal.com]

Папки + линки

[birdwatcher.livejournal.com]

Работать будет, если потребовать, чтобы единственной существенной меткой был полный путь к данному файлу, а все остальные - косметическими.

[balaganski.livejournal.com]

А как быть, если у меня 2 CD-драйва и 3 usb? Как быть с сетевыми ресурсами?

[avva.livejournal.com]

cd1, cd2 автоматически. usb1 usb2. Плюс можно переименовать метку устройства, а система запомнит. "disk on key". "cd writer". "camera".

[e2k-4d-x-ussr.livejournal.com]

да не, вполне нормально.
нынешняя техника и не такую плоскоту потянет.

иерархическая она ж ведь не только из-за порядка выбрана была, а ещё чтобы перебор сузить.

у меня на диске D: полмиллиона файлов.

[tom-ohawk.livejournal.com]

что делать, если на носителе миллионы файлов? придется как-то упорядочивать доступ и к тысячам/десяткам тысяч меток?

Re: у меня на диске D: полмиллиона файлов.

[avva.livejournal.com]

Текущий набор меток всегда достаточно ограничен. Команда аналогичная dir/ls показывает только файлы у которых именно эти метки, а не эти и ещё какие-то другие. Для этого варианта есть другая команда или опции, и тогда это аналогично рекурсивному dir /S или ls -R, который действительно выдаст полмиллиона, как попросили.

Надо только придумать удобные команды, позволяющие узнать, какие есть "поблизости" интересные метки, чтобы их добавить/посмотреть. Не очень ясно, что значит "поблизости", надо подумать. Т.е. проблемы с миллионом файлов нет, а вот с десятком тысяч меток - может быть.

Имя файла

[(Anonymous)]

Имя файла тоже метка ;)

[a7sharp9.livejournal.com]

Так и работают объектные базы данных. ObjectStore, например. То, что Вы описываете, называется View. Но объяснение пользователю, что процесс "скопировать файл" (интуитивный хотя бы на каком-то уровне) на самом деле должен сопровождаться какими-то изменениями меток, каковой концепт и вообще-то человеку не объектно-ориентированному неясен - это точно гибель.

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

[avva.livejournal.com]

Копирование на графическом уровне может выражаться drag-n-drop'ом или копи-пастом. На текстовом что-то типа clone filename -> newtag.

Прикрутить сверху файловой системы немудрено, ясно, что можно базу данных поставить и всё по ней искать с точки зрения GUI определённых приложений. Мне интересно вот что: можно ли вообще обойтись без иерархической файловой системы. Так чтобы всё было без неё, абсолютно, а не "на нижнем уровне" с ней для администраторов и разработчиков.

[bealex.livejournal.com]

WinFS, PalmOS FS, и что-нибудь еще, основанное не на иерархии, а на базе данных.

[avva.livejournal.com]

WinFS - база данных, прикрученная поверх иерархической файловой системы. Это не очень интересно. Интересно совсем и полностью без иерархической файловой системы, но чтобы было не менее удобно, причём не только чайникам, но и продвинутым пользователям (может, непривычно вначале, но в итоге не менее удобно).

[anton.livejournal.com]

Зачем существенные и несущественные метки? Можно просто запретить существование файлов с одинаковыми наборами меток. Т.е. метки, как и сейчас путь — считаются частью имени.

[avva.livejournal.com]

Ага, см. апдейт в записи.

[melkin.livejournal.com]

Возможно это не интуитивно для програмиста, но пользователь-то будет работать с графическими программами - copy-paste, drag and drop, ему будет просто.

[screamager.livejournal.com]

Не будет работать? Слишком сложно? Слишком неинтуитивно?

Конечно. Фигня все эти метки. Точнее не фигня, а мелкий полезный инструмент, типа этих жёлтых post-it наклеечек. но мы ведь не пишем всё на этих стикерах? Вот и метки не надо притягивать за уши ко всему подряд.

Концепцию файлов и папок человеку, не страдающему олигофренией, можно объяснить за 1 минуту. Никакого бэкграунда при этом не требуется, специальных знаний о компьютере тоже. А если он за минуту не понял, то он и как на клавиатуре работать, тоже не поймёт. Shift какой-то, ctrl. Мутотень.

[romanet.livejournal.com]

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

[slavka.livejournal.com]

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

в итоге каждый сможет пользоваться тем что ему удобнее; кто-то предпочтет скопировать файлы в другой каталог фаром (и при этом у новых файлов автоматически обновятся метки), кто-то будет делать то же самое но через какой-нибудь MS Tag Manager

а вообще идея с метками очень правильная - скажем, когда я запихиваю файл в свою коллекцию софта, каждый раз приходится решать в каком фолдере ему место; скажем плагины для Неро могут быть в multimedia\video\encoders, а могут быть и в hardware\cd\write\nero\plugins

в сличае с метками я просто вешаю обе метки и все ок (некий аналог shared files из VSS)

[avva.livejournal.com]

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

каждый раз приходится решать в каком фолдере ему место

вот-вот, схлопывание многие вопросы упрощает. Проблема разобраться в том, не слишком ли сильно иногда :)

[gxost.livejournal.com]

Будет работать, если это будет дополнением к иерархической файловой системе (а не её заменой).

[slavka.livejournal.com]

иерархическая система - это тоже абстракция (на самом деле файлы вовсе не сидят на винте аккуратными группами ;) )
иерархическая система - частный случай системы меток

[ex-ex-zhuzh.livejournal.com]

Гмм… что делать в ситуации, когда у двоих людей есть разные файлы с одинаковым именем? Скажем, что есть метки косметические, а есть существенные. Существенные метки являются частью идентичности файла; могут существовать два разных файла с одним именем, но разным набором существенных меток. Но если набор существенных меток одинаков и имя одно и то же, это один и тот же файл (у которого можно менять набор косметических меток) (update: возможно, косметические метки не нужны, пусть все будут существенные?).

Имя файла — такая же метка, как все остальные, только обязательная (есть у каждого файла). А может быть, и необязательная. В самом деле, почему? И зачем нужны (явные) существенные метки вообще?

[avva.livejournal.com]

Ясно, что есть ситуация, когда у двоих разных пользователей есть файл, отношение к которому у них идентично: например, это фотография их кошки. Если у этого файла есть имя, они оба назовут его cat.jpg. Есть есть метки, они оба, положим, дадут одинаковые метки. Каталогов у нас нет. Нужен способ их различить. Понятие существенной метки (в данном случае по имени юзера) позволяет это сделать. Хотя я уже перестал видеть смысл в не-существенных.

Насчёт необязательности имени файла: да, тоже правильное замечание. Что тогда делать с расширениями? Они все естественным образом переходят в метки?

[iliat.livejournal.com]

Filesystem as a database -> WinFS
Sometimes hierarchical views are useful and you could support them by allowing user to create "on the fly" taxonomies of labels.
Oh, and the main method of file access should be google like text search that is smart (searches labels, then contents).

[avva.livejournal.com]

Да, позволить создать иерархию из меток, если хочется - об этом я тоже думал. Не очень ясно, как это сделать интуитивным.

WinFS - ну что ж, я не надеялся, что что-то новое изобретаю :) но интересно будет на это посмотреть, конечно.

[ex-fractaliz864.livejournal.com]

Возникают проблемы с конфигами, если их хранить в разных файлах.

[dzz.livejournal.com]

Какие??????

[dzz.livejournal.com]

> У каждого файла есть набор меток

В системах управления контентом (aka ECM) это называется атрибутами :)

Проблема в том, что плоский набор атрибутов в определённый момент разрастается настолько, что становится неуправляемым. Кроме того, сама природа атрибутов зачастую требует внутренней логической организации. Например, структурной группировки (страна-город-улица-дом, объект-блок-запчасть), зачастую, вариативной (т.е. набор атрибутов в разных ветвях может отличаться). Дерево каталогов и есть пример такой иерархической группировки атрибутов. Так что ничего несуществующего ты не предлагаешь :)

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

Самая существенная проблема, IMHO, в том, что разумный потребитель информации (aka человек :) сам склонен иерархически группировать свои знания о мире, так что плоская картина просто не соответствует его потребностям.

[dzz.livejournal.com]

Собственно, рекомендую погуглить по кодовому слову ECM

[novice.livejournal.com]

пару random ссылкок (еще не прочитал все комментарии):

http://arstechnica.com/reviews/os/macosx-10.4.ars/ - пара страниц о metadata и extended attributes, очень хорошо

ну и http://www.nobius.org/~dbg/ "Practical File System Design with the Be File System"

[sergeax.livejournal.com]

Также надо экспортировать списки последних изменённых и добавленых файлов по комбинации тэгов - и FileSystem 2.0 готова, можно искать инвесторов.

[ly0lik.livejournal.com]

примерно это и будет на том компутере от Google, который уже не будет компьютером в привычном понимании, а будет еще одним простым домашним прибором.

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

[smilga.livejournal.com]

Иерархическая организация очень естественна для человеческого мышления, поэтому совсем плоская система меток будет столь же неудобна, как и жестко древовидная структура (впрочем, кому как). Мне кажется, был бы разумен вариант с иерархической организацией самих меток; данному файлу, разумеется, можно присваивать метки из разных иерархий.

[cema.livejournal.com]

Да, это разумный вариант.

[http://users.livejournal.com/magister_/]

Копирование должно создавать ФИЗИЧЕСКИ новые копии, иначе проблемы будут.

Кроме иерархии, есть еще симлинки.

[drlazy.livejournal.com]

Даа, раззадичили вас. Насколько я понимаю данный пост инспирирован откликами по GoogleOS :)
Реально нужно по-моему объявить не fopen, а system_fopen и user_fopen в первом открывается все, во втором принадлежащие данному пользователю. И все, никаких проблем.

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

[(Anonymous)]

Согласен с dzz
Введение тэгов, или аттрибутов - суть таже иерархия, но менее одназначная
Такая систематизация в конце концов выльется в проблему поиска нужного файла с гораздо большим количеством условий

[kot-begemot.livejournal.com]

В общем, тут и до меня многие высказали здравые мысли, но поскольку тема мне близка (всё-таки последние 6 с гаком лет отданы файловым системам и вообще хранению данных) позволю себе заметить, что реально всё очень и очень зависит от предметной области. Иерархические файловые системы применяются довольно широко, но отнюдь не универсально. Комплиментарными являются объектно-ориентированные (типа того же ObjectStore, Versant) и реляционные (Oracle, xSQL) базы данных. Несколько особняком стоят проблемно-ориентированные решения типа Documentum. Кстати, идея меток имеет вполне официальное название - CAS (Content addressed storage) и в разной мере реализуется как в железе (напр. EMC Centera), так и в софте - тот же Documentum.
Плюс к этому, существуют ещё решения для data warehousing (как правило так или иначе основанные на CAS и/или БД), а также решения для данных в развитии - от простой поддержки версий типа ClearCase, до многоуровневых решений класса ILM (Information Lifecycle Management), где информация в зависимости от её текущего состояния может храниться на том или ином носителе.

[ex-ex-zhuzh.livejournal.com]

Я хочу для домашнего десктопа файловую систему подобрать. Что посоветуете? ;)