Изобретен новый способ хранения файлов

> Проблемы начнутся когда тетке понадобится ввести категорию "Рецепты от соседки Галины Петровны"

Лишние сущности плодите, батенька. Старик Оккам мигом бы своей бритвочкой все исправил, но увы и ах.

Одна из главных проблем - это всех строем нельзя пересадить на одну FS, даже если она мегакрутая. То-есть надо быть над нативной файлосистемой даже если она оффтопична. Поэтому линки не катят (и ещё и потому что надо поддержать урлы - ресурсы вне файловой системы и пр). И аттрибуты FS тоже.

CMS тоже не катит (можно было-бы запихнуть всё туда) частично по той-же причине (нельзя перезапихивать): я хочу заиндексировать (забукмаркить) например работающие конфиги в существующей FS или большом read-only volume. То-есть индекс должен быть _дополнительной_ метадатой.

Подведем итоги: "Оракел в каждый сопливый embedded-device!"

Смотрю на эту жуткую полемику и думаю - а на кой черт функциональность внешних сервисов засовывать в FS? Давайте тогда засадим туда же нативные мейл-боксы, календарик, систему контроля версий, криптографию, полное разделение контента и заголовков (типа чисто внешних id3-tags, с выдергиванием по контрольной сумме) - э? Поверх всего ужоснаха присобачим слой поддержки отсутствующих ресурсов (типа внешний линк на mms-ресурс на упавшем сервере).

После чего снизойдет на нас стабильность, скорость и в особенности - благодать апосля трехневного ожидания поиска 100 байт данных по чудному ключу "рецепты от дяди Маши" на 256-метровом разделе.

Предлагаю начать пользоваться хотя-бы текстовым индексов (потом вы на него подсядите - уверяю вас):

1) Создайте диру ISROOT где нибудь или "ln -s / ISROOT". Кладите всё (документы, архивы итп) туда.
2) Создайте диру ISROOT/INDEX
3) Если кладёте что-то под ISROOT (под любым оригинальным именем) - создайте текстовый файл под INDEX с именем вашей ассоциации. Внутри файла - строка пути/URI к оригинальному файлу.

По мере увеличения файлов-ключей - передвигайте ключи в директории (если файло-система не поддерживает большого количества файлов в дире.
Например - файл projects идут в P.

Если файл ключа существует - добавляем новую строку.

Надо что-то найти - простой "cat /ISROOT/INDEX/keyword" или "cat /ISROOT/INDEX/K/Keyword" - за линейное время (написания). Время поисков - ноль, при столь угодно большой файлосистеме (ну, logarithmic;)

Класть тоже можно "echo /ISROOT/fileOrPath >> /ISROOT/INDEX/keyword"

Тут даже софта не надо - это просто подход.
А с веб-интерфейсом и поддержкой пересечения групп (для более одного ключа) - получаем гугель над нашими ассоциациями/иендексом.

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

Может проще `man beagle`, э?

Доступ к инфе и так шустрый, всего делов - открыть файлик. Проблема сидит в мозгах, кои посредством кривых рук легендарные помойки разводят, да полагаются на "авось" и "не забуду" в мутной надежде на светлое будущее.

> Интересно, кто-нибудь напишет для fuse модуль, строящий файловую систему на основе, например, тегов mp3? Полезная вещь получилась бы.

Вы страшно удивитесь, но существует модуль FUSE для Beagle

> Имеет значение анализ информации. На лету. Сливаю я фотографии, и оно само отмечает "это портреты а это пейзажи, это Вася а это Маша".

Портреты с высокой степенью вероятности можно определить по тэгу EXIF :)

Что касается Маши и Васи, ручная простановка меток после импорта занимает в реальности так мало времени, что и париться особо не надо.

не везде есть mono и есть beagle. Я хочу одну базу - при работе под оффтопом, AIX, OS390 и желательно на USB брелке. Текстовые файлы _уже_ выполняют эту задачу. В будущем захочется иметь доступ с телефона, PDA итп

> Файлами должны управлять ПРИЛОЖЕНИЯ. Вроде Amaroc, ACDSee, iTunes, WinAmp, Photoshop etc.

Куда тебя послать ?
Я закачал firefox'ом фотографии - 100 штук. Мне теперь firefox запускать чтобы их посмотреть ? вместо нормального просмотрщика смотреть медленно и по одной firefox'ом не имея возможности развернуть на 90 градусов какую-то фотку ?
И отредактировать фотожопом не смогу фотку, ведь "ей управляет приложение firefox".
А если я захочу на CD записать, то этого сделать не смогу - firefox диски не пишет.

потом beagle - это search tool, а это как я сказал - ортогональная задача. Для того и find/grep есть.
От помоек всё равно не обойтись. А вот организовать моментальный доступ к любой инфе прошедшей через вас когда-то - это экономия времени. Открывать файлик надо в любом случае - это никто не отменяет.
Предлагается инструмент - чтобы быстро найти тот самый файлик (не через новый search, который кстати вы и не сможете так просто сделать: единственные критерии - это то что вы помните о той инфе, то есть ваши ассоциации)

Простой формат мог бы быть таким:
example file: ISROOT/INDEX/indexing
---8<---
ais/
http://www.linux.org.ru/view-message.jsp?msgid=1640761#1642326
# this is a comment and will be ignored
http://www.dba-oracle.com/art_9i_indexing.htm
some/another/path/to/a/local/resouce # this also will be ignored
---8<---

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

Затем, что это проще!, чем на каждый скопированный файл еще писать парочку ключевых слов перед сохранением.

Все что надо - это пропатчить find и locate для распознавания тагов, и файловую систему, чтобы хранила в extended attributes несколько больше информации о файлах чем сейчас, и чтобы locate заносил эту доп информацию в свои индексы и умел искать по ней.
> Кому-то нравится по любому поводу лазить в консоль и по сто раз запускать просмотрщики/прослушивательщики?
> На здоровье. Только не называйте это потом мейнстримом :)

+ GUI frontend к патченному find и патченному locate - вот уж не проблема написать.
Сейчас в приложении поиска KDE есть шаблоны но не хватает возможности искать используя AND + по дополнительной инфе в extended attributes , + по тагам стандартных форматов.


Сегодняшняя иерархическая система лучше - я могу кидать файлы не переименовывая в директорию с внятным названием, потом найти по названию эту директорию и посмотреть что там за файлы.
Мне надо только один раз на 10-100 файлов придумать ключевое название директории, а именовать каждый файл - это по желанию.
А предлагается на каждый файл гемороится придумавать ключевые слова.

>> А с обычными файлами она сварганит папочку "Рецепты", в ней - "Торты",
> А если потом захочет организовать в группу все рецепты данные тётей Клавой, и незахочет делить книгу полезных советов, в которой тоже есть рецепты тортов и не только?

для этого пихаются дополнительные к имени директорий/файла ключевые слова в еxtended attributes. locate+GUI их ищет и выводит.

/рецепты/торты/наполеон.txt , в ExtAttr к нему пишем ("тетя Клава" "маша одобрила")
или
/рецепты/тетя клава/наполеон.txt , в ExtAttr ("торт","маша одобрила" )

естественно все через GUI.

>Все что надо - это пропатчить find и locate для распознавания тагов
не везде будет работать. Многие вынуждены работать под оффтопиком например. cygwin как костыль - не предлагать

>Сегодняшняя иерархическая система лучше - я могу кидать файлы не переименовывая в директорию с внятным названием, потом найти по названию эту директорию и посмотреть что там за файлы.
Мне надо только один раз на 10-100 файлов придумать ключевое название директории, а именовать каждый файл - это по желанию.
А предлагается на каждый файл гемороится придумавать ключевые слова.


абсолютно то же самое, где ваша дира - это просто _одно_ ключевое слово.
Предлагается просто расширить возможность, чтобы класть вашу группу файлов но сразу в 2 или несколько директорий (настаиваете на 1 - на здоровье)
Директории для группировки файлов никто не отменяет.

Я так и делаю (slash at the end means - group of files:
file INDEX/rock
---8<---
music/Deep Purple/ # oznachayet directory with concert
19931232/PinkFloid/
some/long/path/WhishYouWereHere/
music/sbornik/some/path/some_single_composition.mp3
ddt
...
---8<---

но также и
file INDEX/подборка_cool_3
---8<---
music/sbornik/some/path/some_single_composition.mp3
another/path/to/a/single.mp3
...
---8<---

то-есть вы создаёте много групп над одними и теми-же композициями и даже можете типа "cat INDEX/подборка_cool_3 | xargs yourplayer" иногда

тоже - с линками, книгами, рецептами, блин

в идеале - да.
Но EA нет в других FS, а дождаться везде их - мягко говоря нереально.
INDEX работает сейчас и везде Ж)

Да есть, EA, есть. Прямо сейчас. Прямо у вас на линуксе. man mkfs.xfs. Но пользоваться ими в рамках существующего API (которое, прямо скажем, сбоку-припёку) просто боязно. Поэтому народ и городит внешние каталогизаторы, которые всю базу хранят или внутри каталогизируемого файла, если его формат это позволяет (например, HTML с его meta), или во внешнем хранилище.

И, мой прогноз, ситуация не изменится до тех пор, пока не будет кардинально переделан _POSIX'овый_ файловый API и заметная часть "стандартных" интернет-протоколов так, чтобы работа с расширенными атрибутами стала неотъемлемой их частью, а и этот API мало того что будет реализован в линуксе, но и всякими MS'ами, Эпплами и прочими "имитаторами" (ну, ладно, внутри Darwin - почти настоящий юникс :-)). По-моему, этого не произойдет никогда.

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

> Затем, что это проще!,

Проще? Проще признать, что Вы не прочитали, что я написал :)

Ещё раз: создав "умный" список воспроизведения в проигрывателе, я могу сразу послушать давно не слушанное. Ключевое слово: "сразу". Это значит, что я увидел нужное в списке отсеянного, щёлкнул по нему -- и воспроизведение началось, прямо там -- в окне проигрывателя.Если я полез в консоль, мне до КАЖДОЙ найденной песни нужно потом ОТДЕЛЬНО добираться проигрывателем. Нафига такое "удобство"? Кому оно нужно? Гикам? Ну так их число в пределах статистической погрешности.

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

Ахха. Вот Вы приехали к родителям с ноутбуком. "О! - говорят они - "У тебя с собой есть фотографии? А напечатай нам самые лучшие снимки нашей внучки." За десять секунд я запустил каталогизатор и оставил видимыми только фотографии с дочерью, имеющие рейтинг 4 и 5 звёзд. К тому времени Вы максимум успели открыть консоль или поисковик KDE и составить запрос, чтобы узнать в каких каталогах эти снимки могут быть и может даже увидеть часть результатов поиска. У меня уже записался диск со снимками для фотолаба, а Вы всё ещё скроллите свои каталоги по 10-100 фотографий в поисках а) снимков с дочерью вообще и б) лучших из этих снимков. Разница ясна? :)

> А предлагается на каждый файл гемороится придумавать ключевые слова.

Мсье, Вы явно не работали с каталогизаторами вовсе. Иначе Вы бы не написали эту потрясающую своим размахом странность. Говорил ведь -- получится спор евших устрицы с теми, кто их просто видел. Так оно и выходит :)

Для сведения, в каталогизаторе серия из сотни-полутора фотографий размечаeтся минут за пять-десять максимум, включая создание нескольких новых меток, если такая необходимость есть. Это я по своему опыту говорю. Буквально вчера вечером пришёл с концерта с примерно сотней кадров и минуты за четыре раскидал их по шести меткам (пяти существовавшим и одной новой), потом отсмотрел и удалил технический и композиционный брак. Безо всяких напрягов, существующих только в голове местных иерархических файлосистемных динозавров.

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

Вы путаете две разные задачи: поиска и представления. Задача поиска - это когда вас интересует некоторое подмножество элементов с заданными свойствами. Задача представления - это задача ориентирования во всём множестве. Решение первой задачи - список, второй - дерево. Поиск нужен, когда вы точно знаете чего хотите. Представление нужно, когда вы интересуетесь тем, что вообще имеется в наличие. Задачи, безусловно, тесно связанные, но разные.

не совсем дерево.

Я имел в виду систему каталогизации...

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

Затея сама по себе грамотная, но... абсолютно бесполезная. Беда всему - непрошибаемая лень и асистематичность юзверей. Они будут годами складывать на десктоп файлы, тасовать по папкам, искать их, тут же забывать и завтра будет твориться то же самое. Конечно, насильственно можно и медведя каталогизировать ягоды, но во-первых, юзверю проще от такой системы ОТКАЗАТЬСЯ, чем себя насиловать, а во-вторых, даже работая с тегами он может давать отсебятинскую метку типа "1" и потом иметь тот же геморой, что имел с обычными папками.

Хаос - он в головах, не в системе.

О чём вообще речь? О физическом способе храненения файлов или о способе анализа метаинформации? Если о первом, то это относится к FS, а если о втором, то это к FS ни как не может относиться! Метаинформация имеет отношение только к конкретному пользователю относительно объекта. Она субъективна. Максимальное приближение FS к метаинформации имеет тогда, когда пользователь один в операционной среде. А если их несколько? И все оперируют одним и тем же банком хранения данных? Представьте себе обычную библиотеку и несколько библиотекарей. Ассоциативность у всех разная. Если они будут переставлять книги ФИЗИЧЕСКИ каждый для себя, то настанет момент, когда ни один из библиотекарей не сможет найти нужную информацию. Проще разделить функционально эти области. FS размещает файлы физически в соответствии со своими жёсткими правилами, а метаинформация относится к пользовательскому окружению. Для пользователя главное не как удобно хранить информацию, а как удобно её найти. Поэтому и существует именно ассоциативный механизм поиска а не хранения. А это к файловой системе не имеет ни какого отношения. Это относится к пользовательскому журналу.

>Похоже, сейчас будет очередной спор между теми кто ел устрицы, и кто их видел.
Последними подтянуться те, кому устрицы высосали моск :-)

>для этого пихаются дополнительные к имени директорий/файла ключевые слова в еxtended attributes. locate+GUI их ищет и выводит.

>/рецепты/торты/наполеон.txt , в ExtAttr к нему пишем >("тетя Клава" "маша одобрила") >или >/рецепты/тетя клава/наполеон.txt , в ExtAttr >("торт","маша одобрила" )

>естественно все через GUI.

Те же яйца - вид сбоку. Какая разница где хранить теги в ExtAttr или в своей базе? Хотя вру, если использовать locate то это и получится - "хранит в своей базе"

Смысл спора не в том, что мы защищаем реализацию описанную в статье, а в том, что мы утверждаем, что плоской иерархической файловой системы уже давно _недостаточно_

> Если я полез в консоль, мне до КАЖДОЙ найденной песни нужно потом ОТДЕЛЬНО добираться проигрывателем. Нафига такое "удобство"?

Справедливости ради, Саша, должен заметить, что поставить в очередь всю пачку не представляется сложным :-)

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

/Anode

Неплохо при этом согласится о каких нибудь стандартах.

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

Так-же вопрос переноса с машины на машину. А неструктурированная информация - для меня например, все равно что отсутствие. Потому что накладные расходы на упорядочиввание - дороже чем сбор нового сырья.

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

И будет добираться до документа откуда угодно -- хоть от рецептов подруги, хоть от рецептов тортов...

Гугль сделал линки, есть букмарки в мозилле... Что мне делать и с одним и со вторым когда я решил, что мне нужна не только метка на документе, но и путь к ней ведущий?

"лор -- обсуждение индексации"

"лор -- споры"

"поиск -- как лучше?"

etc...

Граф с возможностью ходить куда угодно... Хоть торты от тёти груни, хоть слоёное тесто и сладкое на десерт... приведёт к одному документу....

> Справедливости ради, Саша, должен заметить, что поставить в очередь всю пачку не представляется сложным :-)

Ещё большей справедливости ради должен заметить, что ставить в очередь всю пачку надо далеко не всегда :)

> Например сейчас я смотрю фотографии gqview, у него есть средства каталогизации.

У него есть коллекции, они же альбомы. Этого маловато ;)

> Допустим завтра я решу перейти на digikam, но при этом вряд-ли будет возможно перенести структуру.

Проблема ясна. Когда вы вешаете на фотографии метки, нормальные каталогизаторы как правило пишут в JPEG тэги IPTC (если речь о RAW, то пишется так называемый sidecar, то есть дополнительный файл с таким же именем, но другим расширением, скажем, .xmp). При импорте в другой каталогизатор эти тэги должны прочитаться и преобразоваться в метки этого приложения. Соответственно, если первый не умеет писать тэги, а второй не умеет преобразовывать их в метки, начинаются проблемы :)

По-хорошему, выбор софта нужно начинать с выяснения статуса подержки стандартов. Поддержка IPTC для современного просмотрщика графики, претендующего на нечто большее чем "открыл по щелчку из файломенеджера, посмотрел, закрыл" -- это must have.

digiKam в лучшем случае позволит Вам ходить по существующему дереву каталогов. Альбомы придётся создавать заново.

>> Например сейчас я смотрю фотографии gqview, у него есть средства каталогизации.

> У него есть коллекции, они же альбомы. Этого маловато ;)

Ctrl+K

Правда еще не применял :)

Как буриданов осел стою между любимым gqview и модным digikam :)

предлагаю за основу взять текстовый формат приведённый выше. это небольшое отсупление от URI, но изменение имеет массу причин и удобств (rel_path/otnositelno/ISROOT/to/the/locally/mounted/file vs file://bla/bla/bla)

Я много думал над форматом ничего более удобного не найти (тут и privacy (umount private_ISROOT), возможность пайпить файл, модифицировать хоть в ноутпеде, подход масштабируем итд)

/Anode

T.e.
* каждому ключу соответствует файл . Файлы могут быть помещены вглубь иерархии под ISROOT (если данная ФС не масштабируема) на любую глубину.
* Файл состоит из строк (ASCII или UTF)
* каждая строка - или а)относительный путь от ISROOT или б)URI или с)комментарий или д)Линк на другой ключ

да, линков (д) лучше пока избегать (не поддерживаются ни шелловой версией, ни жавовской) и вообще кажется questionable

/Anode

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

То есть либо запрещать иметь дело с файлами непосредственно (что, по видимому утопично, да и не нужно), либо писать метаинформацию в том-же файле.

если правильно понял - предлагаете вставлять таги. 1) большинство оригинальных файлов модифицировать нельзя 2) хочется индексировать read-only разделы и внешние ресурсы (http, ftp итд) 3) всё может быть потеряно - панацеи нет

метадата должна быть дополнителной, легко отделяемой от оригинальных файлов (CVS подход мне не нравится и поэтому и по причине 2), _простой_ и обрабатываемой всеми удобными unix-инструментами (поэтому не xml)

А, и правда :)

>А что такое понимание содержания текста?

А это то, что мы видим в General. Люди смотрят на ман и не понимают, что в нем написано.

>Попробуйте за секунду найти все альбомы 2006 года при стандартном хранении.

Почему-то не разу не возникало такого желания. Но если возникнет, то поиск с регекспом меня спасет. Если кому-то лень учить регекспы, могу лично дя него сделать фронтэнд на питоне.

>> Сперва преимущество неочевидно. А теперь представьте, что при наборе тегов допущена ошибка, набито транслитом или просто на экзотическом языке.

>Ээээ. Это нечестный прием. Это как если бы сказал, а представьте себе если у вас при обзывании файлов допущена ошибка и песня Битлз названа x45dsf453.mp3

Вот видишь. Чтобы обломался поиск, достаточно ошибиться в одной букве или "вычурно" написать. А чтобы обомался традиционный способ, надо полностью убить всю информацию.

>Стоит попользоваться ими некоторое время , чтобы понять, что к стандартному winapm'у уже очень не хочется возвращаться.

Сколько ни сидел в понтовых плеерах, напичканных всякими концепциями, а все равно возвращался к традиционным winAmp/BMP.

>не везде будет работать. Многие вынуждены работать под оффтопиком например. cygwin как костыль - не предлагать

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

>Ещё раз: создав "умный" список воспроизведения в проигрывателе, я могу сразу послушать давно не слушанное. Ключевое слово: "сразу". Это значит, что я увидел нужное в списке отсеянного, щёлкнул по нему -- и воспроизведение началось, прямо там -- в окне проигрывателя.Если я полез в консоль, мне до КАЖДОЙ найденной песни нужно потом ОТДЕЛЬНО добираться проигрывателем. Нафига такое "удобство"? Кому оно нужно? Гикам? Ну так их число в пределах статистической погрешности.

Для создания такого "умного" плейлиста не нужно ничего "изобретать". Все это делается на основе обычной ФС.

> ставить в очередь всю пачку надо далеко не всегда :)

man grep, man find? :-)

P.S. Нет, я музыку играю амароком :-).

<offtop> Кто-нить может объяснить древний анекдот о пользователях МакОС, которым незачем знать, что такое файл? </offtop>

>Ахха. Вот Вы приехали к родителям с ноутбуком. "О! - говорят они - "У тебя с собой есть фотографии? А напечатай нам самые лучшие снимки нашей внучки." За десять секунд я запустил каталогизатор и оставил видимыми только фотографии с дочерью, имеющие рейтинг 4 и 5 звёзд. К тому времени Вы максимум успели открыть консоль или поисковик KDE и составить запрос, чтобы узнать в каких каталогах эти снимки могут быть и может даже увидеть часть результатов поиска. У меня уже записался диск со снимками для фотолаба, а Вы всё ещё скроллите свои каталоги по 10-100 фотографий в поисках а) снимков с дочерью вообще и б) лучших из этих снимков. Разница ясна? :)

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

Ты в сказку попал, что ли?

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

Если в mp3 мне еще не лень заносить мета-информацию, то уж в фотографии - извините...

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

А пример этих шести меток можно? И сколько в каталогизаторе меток вообще со всех фотографий?

случай фотографий - один из случаев где branching не толко не страшно, но и полезно для redandancy (через 20 лет - кто знает что от файлов останется), то есть я всегда делаю копию из всех ISROOT/photo/20061112 в ISROOT/photo/20061112/thumbnales/, ISROOT/photo/20061112/webpublished/
и
echo ISROOT/photo/20061112/ >> ISROOT/INDEX/V/vecherina
echo ISROOT/photo/20061112/ >> ISROOT/INDEX/V/vasya

а если делать подборки над разными датами в последствии - то без индекса не обойтись ;)

Предыдущий пост был мой

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

типа
echo ISROOT/photo/20061214/12341234.jpg >> ISROOT/INDEX/Т/Тёща
echo ISROOT/photo/20061214/12341234.jpg >> ISROOT/INDEX/L/Любимая_Тёща
... <и другие фотки>
echo ISROOT/photo/19050112/987342349.gif >> ISROOT/INDEX/Т/Тёща
echo ISROOT/photo/19050112/987342349.gif >> ISROOT/INDEX/L/Любимая_Тёща

А потом из веб-интерфейса - просто "гуглим" одно из keywords и получаем весь набор across filesystem hierarchy а может и ходя по внешним урлам.

по-моему просто

(с реализацией drag-n-drop и всплывающей диаложкой для ключей, например под мозиллой - и echo посать не надо, однако текстового формата/протокола индекса надо держаться имхо свято)

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

Пока что мой проект (если его можно так назвать) в зачаточном состоянии:

1) написана спецификация .tag файла

2) организован функционал rmedia. Если подробней - это когда файлы могут существовать ка кна моем локальном диске, так может быть ссылка на другое место из списка съемный носитель (обычно DVD-R), интернет (http, ftp), другой компьютер (необязательно в сети). Таким образом, не имя файла на компьютере, я всегда знаю про него все, и могу узнать где его взять (типа "вставьте диск N" или "файл хранится там-то" или "Скачать?"). Я создал такие образы для всех дисков.

3) организован механих dl - когда я создаю список закачек, а скрипт качает из сети и создает к файлам .tag со всей информацией. На самом деле очень удобно, когда я хочу скачать все zip с одного сайта (wget .tag файлы сам не создает)

4) Недописан, но используется механизм ключевых слов, пока что только для видео и иногда для документов. Достаточно создать .tag файл (не вручную, с помощью скрипта) для какого-либо ролика, и указать там ключевые слова типа advertisement, budweiser, funny, как скрипт положит его в директории video/funny и video/advertisement (притом в зависимости от того на одном разделе они или нет, будет либо создан хордлинк или будет сделана копия), а если я в директории advertisement создам директорию budweiser и запущу скрипт, то все файлы рекламы budweiser из директории advertisement перекочуют туда (то есть скрипт ищет самые длинные пути, при том использует все ключевые слоа). Очень полезно, когда не знаешь куда положить доку про принципы настройки фаервола для Линукс - в директорию network/security или os/linux/firewall/iptables или technologies/protocols/l3/ip или technologies/protocols/l4/tcp

Извините за нескромность :)

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

То-то Spotlight у меня в Mac OS 10.4 ищет текст в PDFах. Никак Apple Adobe отпинала как следует. Что мешает тебе?

>>iTunes, кстати, в тему упомянут. Можете прикинуть, как проще найти песню -- при хранении информации в тегах (поиском) или при "стандартном" способе хранения музыки (типа исполнитель/альбом/композиция).

>Попробуйте за секунду найти все альбомы 2006 года при стандартном хранении.

Не надо такие случаи рассматривать. Это приводит потом к попыткам унифицировать и сделать универсальным то, чем не надо ни первого, ни второго. Тебе часто приходит в голову найти все альбомы 2006-го года? Мне ещё такое в голову не приходило, многим, многим другим, думаю тоже. Куда чаще встаёт проблема послушать конкретный альбом такой-то группы. Или "песню, как её там, ну эти её исполняли, что-то про wall, кажется". Или зарядить конкретного исполнителя всего по порядку. Или рандомно. Или вообще все mp3 рандомно фоном, чтобы скучно не было. Вот эти функции надо сделать простыми и очевидными в первую очередь. Задача "найти все альбомы 2006 года" второстепенна. Хорошо, если такая возможность есть. Но если её нет -- не беда. Пример с некорректно записанными тэгами можно отправить вслед за всеми альбомами 2006 года. От этого, как и от ошибок в размещении файлов в директориях никто не застрахован.