Древовидная файловая система имеет некоторые ограничения: имеется 1 корень (или несколько, как в windows), в каждом каталоге могут содержаться другие файлы (и каталоги как подвид), при этом файл может находится только в одном каталоге. Так удобно отсортировывать всё по полочкам, отделять файлы по назначению или ещё каким-то параметрам. Но только на всё это уходит много времени и часто сложно определить точный "подвид" файла.
Например, есть файл с рецептом некоторого полезного для здоровья блюда. С одной стороны его логичнее поместить по адресу "/Рецепты/Полезное для здоровья". Но также можно и "/Полезное для здоровья/Еда".
Или я имею книгу на английском книгу "Дизайн и эволюция C++". Я могу отсортировать положить её как в "/Книги/english/Программирование/Страуструп/С++" так и в "/Программирвоание/C++/Литература/english/Страуструпп". Причём не так много причин предпочесть одно другому. Проблема возникнет, когда я решу найти эту книгу. Я знаю, что мне надо, но не помню точного названия файла и поэтому вынужден буду просматривать все пути.
Частично проблему могут решить жёсткие ссылки. Но опять же надо помещать файл в несколько каталогов. При этом, если я решу создать ещё какую-либо группу (например: "читал" или "прочесть в ближайшее время"). То придётся перебирать кучу файлов.
Наверное, наиболее лучшим решением будет реализация с использованием тегов.
Предположим, появляется у меня файл "Evolution_C++.txt" я навешиваю на него теги: "С++", "Русский язык", "Литература", "Литература/Техническая литература", "Читал", "Программирование". Затем, когда я хочу найти эту книгу, я делаю запрос (или фильтр) "Литература", после чего выбираю подтему "Техническая литература". Затем мне предлагается набор файлов, которые подходят под этот запрос, а также список тэгов, с которыми встречается текущий тег. Среди них я выбираю "С++" и поиск уже сильно сужается — я могу найти нужный мне файл.
Главные отличия — простота и удобство поиска и лёгкость создания тэгов или добавления файла в некоторую категорию. При этом мне должно быть не важно, где файл физически находится.
Теперь вопрос — есть ли что-либо подобное реализованное сейчас?
Здравствуйте, alzt, Вы писали:
A>Теперь вопрос — есть ли что-либо подобное реализованное сейчас?
Не знаю.
A>Древовидная файловая система имеет некоторые ограничения: [..]
Древовидная файловая система, а также файлы, их имена, расширения и атрибуты — весьма мощное и чрезвычайно полезное изобретение.
Некоторую теговость можно усмотреть уже в классической ФС. Например, имя файла — это однозначно один из его тегов, описывающий... да что угодно, главное, чтобы пользователю был понятен хоть немножко. Расширение — это тоже тег, худо бедно описывающий формат файла.
А вот путь — это ни фига не набор тегов. Это адрес коробочки, в которой лежит файл. Несомненный плюс в древовидности системы каталогов — это то, что этот самый адрес можно записать в строчку по принципу "от общего к частному". Не знаю как кому, но мне удобно, что:
1. Каждая единица хранения информации однозначно идентифицируется полным путём. И этот путь более-менее стабилен.
2. Существует простой "естественный" способ перебора всех мест багажа.
3. Иерархичность файловой системы естественна для базовых операций человеческого восприятия — от общего к частному и наоборот.
Неудобства начинаются тогда, когда в иерархию мы пытаемся внести какой-то смысл. Довольно быстро обнаруживаем, что понятия "общее" и "частное" выделить иногда трудно, а иногда и невозможно. Особенно когда категории в принципе ортогональны.
Разложить музыку по исполнителям? Или по авторам? Рок и поп логично разложить по исполнителям, а классику — по авторам (хотя я знаю эстетов, раскладывающих классику по исполнителям, ибо для них это более существенно).
Например, я хочу хранить отчёты по продажам, расходам и финансам за разные годы в разных каталогах. можно сделать так:
Отчеты
2007
Продажи
Расходы
Финансы
2008
Продажи
Расходы
Финансы
2009
Продажи
Расходы
Финансы
Как лучше? Какой разрез главнее? Да никакой не главнее! Они ортогональны! Какой вариант я выберу? Если меня больше волнует расшаривание папочек и управление правами доступа, выберу первый. Если меня больше волнует возможность лёгким движением руки закатать всю годовую отчётность в архив и унести на флэшке домой, то выберу второй вариант. Если меня беспокоят обе эти проблемы, буду изображать из себя буриданова осла.
Смогли бы теги мне чем-нибудь помочь в этой ситуации? Теоретически — да, но для решения этой частной проблемы от ФС потребовалось бы следующие фичи:
1. Возможность назначения прав доступа на теги. Интересная тема. Кто-нибудь её прорабатывал? Как это сделать так, чтобы ни админ, ни пользователи не сошли с ума?
2. Возможность оперирования набором объектов, лежащих под тегом (набором тегов) как единым целым: скопировать, переместить, удалить, запаковать в архив, вынуть из архива и т.д.
То, на что ориентированы существующие теговые системы — это исключительно поиск после предварительно проведённой работе по навешиванию тегов. Ребята, поиск — это, конечно, важно и модно, но это отнюдь не всё, что мне нужно от файлохранилища. Пока всех заклинило на поиске, не будет нам щастья.
А с точки зрения организации складского хозяйства (согласитесь, это — самая главная функция ФС) древовидная структура — это очень и очень хорошо.
Здравствуйте, alzt, Вы писали:
A>Теперь вопрос — есть ли что-либо подобное реализованное сейчас?
По идее было бы круто иметь какой-то всеми разделяемый способ прикреплять к файлу xml'ку с описанием. Типа там должно быть основное поле "неформальное описание файла", возможно можно иметь описания на разных языках + какие-то переменные.
Дальше можно было бы
1) Индексировать и искать по этим описалкам
2) Иметь редакторы таких описалок для каких-то специфических случаев, скажем для закачки с фотика, для музыки, для файла из торрента и т. д.
3) Иметь описалки не только на файл но и на каталог.
Ну и как-то среди этого всего искать.
Как искать -- вопрос отдельный. Мне нравится тутошнее предложение иметь виртуальный диск, папки в котором -- это иерархические запросы.
Типа будет легко из любой проги сделать запрос, уточнить его, и т. д...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, Lloyd, Вы писали:
L>Здравствуйте, alzt, Вы писали:
A>>Теперь вопрос — есть ли что-либо подобное реализованное сейчас?
L>Обычно с такими задачами неплохо справляется поиск (исключая Читал/Не читал).
Неужели?
А такой пример. У меня есть папка с фотографиями. Имена фотографий сами пониманиете какие — img_1234.jpg. Как теперь мне найти все фотографии с моим дитём? Я конечно могу все фото с дитём положить в отдельную папку. И туда же попадут фото с разными событиями жизни — ДР, Отпуск, Дача и т.д. Как тогда найти все фото из Отпуска? Можно, конечно давать файлам имена, например, Дитё_Отпуск_Лето_2008.jpg. А если категорий больше? Все категории в имя файла не запишешь.
A>Хочется хорошей интеграции с существующими программами. A>То есть, например, сделать фильтр по направлению музыки и добавить это всё в список воспроизведения.
Если я правильно понял, то ты хочешь, чтобы дерево папок выглядело как-то так:
Music
Tags
Rock
Band 1
Band 2
Band 3
Blues
Band 2
Band 3
Pop
Band 1
Band 2
Country
Band 1
Band 2
Reggae
Band 2
Dance
Band 3
Club
Band 1
Techno
Band 1
Если всё так, тогда готовых решений я не знаю, но могу рассказать как приготовить такое самому. Если вкратце, то способа два — относительно лёгкий и сложный. Лёгкий заключается в использовании бесплатного движка Dokan (поддерживаемые ОС и платформы надо бы уточнить, но у меня на Windows XP x86 завелось без проблем, по идее на Vista тоже должно работать). Движок содержит драйвер файловой системы (FSD) со службой и библиотекой для взаимодействия со всем этим делом, при чём всё доступно в исходниках и даже с примерами. Позволяет эта штука создавать виртуальные диски с кастомной файловой системой, т.е. содержимое, структуру и т.п. определяешь ты. Можешь хоть реестр туда запихнуть (там примеры на C# есть), и он там будет отображаться в виде папок и файлов (прикольно, да?). Всё, что требуется от программиста — это написать код обработчиков (можно писать как на managed-языках, так и на unmanaged). Как правило, достаточно написать код для callback'а, который запрашивает у тебя содержимое папок. Т.е. если по вышеприведённой структуре, то получится примерно так:
1. Приходит запрос QueryDirectory на путь Z:\Music\Tags\Rock.
2. Вызывается твой обработчик и ему передаётся этот путь.
3. Выделяешь конечное имя папки Rock — это тег.
4. Читаешь список групп, которым назначен тег Rock.
5. Пишешь этот список в буфер запроса, как показано в примере.
6. В итоге в Проводнике (и не только) видишь в папке Z:\Music\Tags\Rock подпапки "Band 1", "Band 2" и "Band 3".
По поводу того, откуда взять список исполнителей для каждого тега. Ну тут можно какое-нибудь своё хранилище на C# напедалить, делов-то, типа своя мини-БД. Чтобы создать такую базу, скачай где-нибудь код на C#, выдирающий значение поля "Жанр" из MP3-тегов и накатай на коленке утилитку, которая будет обрабатывать все музыкальные файлы, которые ты хочешь запихнуть в эту мини-БД. При каждом запросе на шаге 4 будешь отправлять запрос к своей базе. Ну в общем, база — это чисто твоя забота, т.е. в колбеке тебя спрашивают "что отобразить в папке?", — ты возвращаешь список, всё просто. Единственный недостаток у этого движка — на больших объёмах (большое кол-во элементов в папке) начинает тормозить, т.к. всё взаимодействие с драйвером идёт через службу, а со службой через пайпы, и получается не оптимально. Ну зато бесплатно и с исходниками.
Собственно, второй вариант это написать драйвер-фильтр файловой системы. Это на порядок сложнее, но зато оптимально, производительно и highly-customizable. Если реально надо всё это — могу написать, но не забесплатно, разумеется. Вон там внизу по ветке человеку тоже нужно, ну скиньтесь тогда что ли, если дорого. Найдёте альтернативу — дайте знать, интересно будет взглянуть.
Здравствуйте, alzt, Вы писали:
A>Здравствуйте, carpenter, Вы писали:
C>>В связи с этим вопрос — есть два варианта сортировки по тегам - C>>один в виде виртуальной папки C>>второй в виде дополнительного интерфейса к программе C>>Какой был бы предпочтительней для вас ?
A>Глядя на скриншоты я не увидил никаких тегов или категорий. Только описание файла. A>Это ещё не реализовано или скриншоты такие?
со скриншотами все норм
действительно не реализовано ... просто была мысль это сделать ... а потом , я немного полежал , и она прошла
думал неинтересно никому
A>Насчёт предпочительного способа сложно сказать, трудно определиться ни разу не попробовать.
будем попробовать ... как сделаю — скину в эту ветку
A>Скорее всего виртуальные папки, но всё зависит от многих деталей (особенно скорости работы).
тут сложно сказать , перформанс заранее просчитать сложно
x64>>Есть мысль написать такое и продать Microsoft'у для внедрения в массы. ЮЖ>А сколько, навскидку, это человеко-лет?
А это сильно зависит от того, кто будет работать над этой задачей — профессионал или супер-профессионал ) Я не отношу себя ни к тем ни к другим, но если бы я взялся за написание подобной теговой файловой системы, то у меня это заняло бы что-то около 1,5 — 2 года (плюс-минус конечно). Тут только на формулировку задачи уйдёт пару месяцев. В прочем, на мой взгляд сроки весьма оптимистичные. Я не знаю точно, почему Microsoft отказалась от WinFS, но мне кажется, что они не упустят возможность приобрести готовое и легко встраиваемое решение. А если не они, то есть ещё несколько крупных и всем известных компаний, которые вполне могут оказаться потенциальными покупателями.
ЮЖ>Можно с помощью NSE выставить папки в локальную сеть?(нет)
Насчёт NSE не знаю, но с помощью драйвера-миниредиректора можно (если я правильно понял, о чём речь).
ЮЖ>Можно с помощью драйвера получить несколько файлов с одинаковыми именами в одной папке?(я не знаю правильного ответа, но что-то мне подсказывает, что нет).
А еще очень помагает категоризация. Скажем определенная папка -- это категория. Скажем /Программирвоание/C++/Литература/english/Страуструпп -- это всё категории. Категория "Литература" не может относиться к С++ так как, как понятие, намного содержательней. Поэтому будет лучше так: English/Литература/Программирование/C++/Страуструпп. Да и если английский используем, то лучше его использовать уж везде, во всех названиях категорий.
Вообщем, используя категоризацию мне ненужны: теги, google desktop и очень редко использую поиск.
Здравствуйте, alzt, Вы писали:
A>Здравствуйте, Рома Мик, Вы писали:
A>>>Да. Это в общем и требуется. Файловая система сейчас слишком нужна для поиска. В идеале сократить её до минимума (по физическим носителям). Оставить возможность как-то группировать файлы, но такая возможность будет просто никому не нужна. РМ>>Она может быть и не будет нужна с точки зрения пользователя. А многим она и не нужна, недаром в windows сделали папку "Мои документы" куда предлагается всё сваливать в кучу, что очень многие и делают. А вот с точки зрения системы очень даже нужна, потому что надо как-то отличать файлы относящиеся к разным сущностям: здесь у нас файлы пользователя (а кстати только им и нужна система тегов, остальным вообще не нужна), а здесь файлы программы А, здесь файлы программы Б, здесь драйвера.
A>Я описываю только пользовательские данные. Служебные пользователь вообще трогать не должен (кроме конфигурационных).
Ну так пользовательские проблемы надо на пользовательском уровне и решать, зачем файловую систему трогать-то? Поставь себе Евфрат какой-нибудь и наслаждайся. А рядовому пользователю этого вообще не надо, они скидывают всё в общую помойку, а когда надо найти что-то, говорят, что потерялось, и делают новое, если действительно нужно
G>>>и к фото, но тут трудоемкость затэгировать одну-две сотни фоток раз в месяц гораздо сложнее, чем решить раз в жизни задачу "Все фотки с Васей". РМ>>См. фконтакте. Просто фотки надо там хранить и всё. (сам правда не пользуюсь и не планирую)
G>фотки там хранить невозможно.
Вот-вот!
Кстати хороший пример с фотками. Я использую прогу для катологизации фоток, там назначаю фоткам категории/тэги/людей, а сами файлы сваливаю в одну кучу, т.е. так как их делает фотоаппарат. Получается очень удобно — можно выбрать и посмотреть то что хочешь (местность, человека, дату и т.д.) не заморчаваясь на реальное расположение файлов.
Плюс папка с музыкой тоже добавлена в медиабиблиотеку в фубаре, так же очень просто можно делать различные выборки не задумываясь где музыка есть на самом деле.
Было бы ну просто очень нереально круто если бы эта система тэгов/категорий работала на уровне файловой/операционной системы, что бы любая прога могла её использовать
Здравствуйте, race1, Вы писали:
R>~15 тысяч. Не все мои, не все представляют большую ценность, но почти все с тегами. Это ещё зависит от того, как вести...
А ты можешь хотя бы на глаз прикинуть сколько времени на это ушло и сколько раз и в каких ситуациях это пригодилось?
R>Пусть так, но тэги таки дают преимущество над древовидной структурой?
Да фиг там. По настоящему будет рулить такая система: в метаинфе прописано "Это Иван Иваныч (линк на записную книжку) и Маша на вечеринке у Пети в августе бухие под столом неодетые" и возможность нормаьного поиска по такой инфе
ЮЖ>Вот это я имел ввиду под "привязкой" к пути (хотя в драйверах наверняка какие-нибудь другие имена/идентификаторы можно использовать).
Не только в драйверах. Но много ли ты видел приложений, умеющих использовать NTFS'ные идентификаторы (речь о File ID и Object ID)? Вот в этом и проблема.
A>Теперь вопрос — есть ли что-либо подобное реализованное сейчас?
А ты уверен, что тебе это нужно именно в виде файловой системы? Вообще-то то, о чём ты говоришь, называется БД. Ну если уж нужно именно ФС, то драйвер-фильтр написать самому совсем не сложно.
Здравствуйте, alzt, Вы писали:
A>Добрый вечер.
A>Древовидная файловая система имеет некоторые ограничения: имеется 1 корень (или несколько, как в windows), в каждом каталоге могут содержаться другие файлы (и каталоги как подвид), при этом файл может находится только в одном каталоге. Так удобно отсортировывать всё по полочкам, отделять файлы по назначению или ещё каким-то параметрам. Но только на всё это уходит много времени и часто сложно определить точный "подвид" файла.
Что-то подобное, кажется, хотели реализовать в WinFS (еще в Висте, но не успели), одно время по ней было относительно много статей, но в последнее время ничего не слышно. Вроде бы разработчики решили не выпускать ее в виде отдельного продукта, а использовать наработки в SQL Server'е и других разработках.
Здравствуйте, alzt, Вы писали:
A>Добрый вечер.
A>Теперь вопрос — есть ли что-либо подобное реализованное сейчас?
Как уже заметили с этим хорошо справляется поиск. А еще лучше поиск в Google Desktop. Индексация файлов присутсвует, что делает поиск значительно быстрее. Можно еще воспользоваться стандарным Windows Search Service. ИМХО Google Desktop лучше.
"Не волнуйся, голова! Теперь будет думать компьютер"
Гомер Джей Симпсон
Здравствуйте, alzt, Вы писали:
A>Добрый вечер.
... A>Наверное, наиболее лучшим решением будет реализация с использованием тегов.
Добавлю: нужны типизированные(числа, строки, даты) иерархические теги. Последние — это контейнеры + замена для "Литература/Техническая литература". "Литература" — это имя списка, а "Техническая" — одно из значений.
A>Теперь вопрос — есть ли что-либо подобное реализованное сейчас?
Что-то вроде этого?:
Здравствуйте, x64, Вы писали:
A>>Теперь вопрос — есть ли что-либо подобное реализованное сейчас?
x64>А ты уверен, что тебе это нужно именно в виде файловой системы? Вообще-то то, о чём ты говоришь, называется БД. Ну если уж нужно именно ФС, то драйвер-фильтр написать самому совсем не сложно.
Хочется хорошей интеграции с существующими программами.
То есть, например, сделать фильтр по направлению музыки и добавить это всё в список воспроизведения.
Здравствуйте, UDI, Вы писали:
A>>Добрый вечер.
A>>Теперь вопрос — есть ли что-либо подобное реализованное сейчас?
UDI>Как уже заметили с этим хорошо справляется поиск. А еще лучше поиск в Google Desktop. Индексация файлов присутсвует, что делает поиск значительно быстрее. Можно еще воспользоваться стандарным Windows Search Service. ИМХО Google Desktop лучше.
Google Desktop не использовал. Посмотрю.
Индексация — это хорошо, но не то, что мне нужно.
Файлы не обязательно могут быть текстовые, а любого другого формата (Видео, двоичные данные).
Идея использовать набор некоторых тегов (разных типов, не только строковых) вместо пути файла.
Здравствуйте, TheOldMan, Вы писали:
TOM>А еще очень помагает категоризация. Скажем определенная папка -- это категория. Скажем /Программирвоание/C++/Литература/english/Страуструпп -- это всё категории. Категория "Литература" не может относиться к С++ так как, как понятие, намного содержательней. Поэтому будет лучше так: English/Литература/Программирование/C++/Страуструпп. Да и если английский используем, то лучше его использовать уж везде, во всех названиях категорий.
TOM>Вообщем, используя категоризацию мне ненужны: теги, google desktop и очень редко использую поиск.
Не всегда понятно какая категория более общая. В примере выше — мне не нравится, что english — это более общая категория. Если я хочу посмотреть все книги по С++, то мне придётся искать в двух папках ("English/Литература/Программирование/C++/Страуструпп" и "Русский/Литература/Программирование/C++/Страуструпп") вместо одной "/Программирвоание/C++/Литература" (или "/Программирвоание/C++/Литература/Страуструпп", если хочется конкретного автора).
Здравствуйте, Юрий Жмеренецкий, Вы писали:
A>>Добрый вечер. ЮЖ>... A>>Наверное, наиболее лучшим решением будет реализация с использованием тегов. ЮЖ>Добавлю: нужны типизированные(числа, строки, даты) иерархические теги. Последние — это контейнеры + замена для "Литература/Техническая литература". "Литература" — это имя списка, а "Техническая" — одно из значений.
Да всё это нужно.
A>>Теперь вопрос — есть ли что-либо подобное реализованное сейчас? ЮЖ>Что-то вроде этого?:
ЮЖ>
Судя по картинке да. Извиняюсь за безграмотность — что это? Уж не виста случайно ли?
Важно ещё лёгкость добавления тэгов,или файлов к категориям.
Ещё должны автоматически добавляться те характеристики, которые можно втоматически добавить. Например, в примере выше можно автоматически получить название альбома и имя исполнителя.
Здравствуйте, alzt, Вы писали:
A>Теперь вопрос — есть ли что-либо подобное реализованное сейчас?
Не знаю, но ты точно не первый, кого заинтересовал этот вопрос. Иерархическая файловая система уже задрала — это просто идеотизм. А всякие гугл десктоп — это заплатка для идиотизма. Я даже в порыве чувст хотел написать какую-нибудь оболочку для работы с файлами через тэги. Но это тоже илиотизм, так как решение должно быть именно на уровне файловой системы.
Давно еще когда в первый раз этим вопросом задался, нашел в интернете "tag based file system". Жду когда же такое появится в винде.
Здравствуйте, Spiceman, Вы писали:
S>А такой пример. У меня есть папка с фотографиями. Имена фотографий сами пониманиете какие — img_1234.jpg. Как теперь мне найти все фотографии с моим дитём? Я конечно могу все фото с дитём положить в отдельную папку. И туда же попадут фото с разными событиями жизни — ДР, Отпуск, Дача и т.д. Как тогда найти все фото из Отпуска? Можно, конечно давать файлам имена, например, Дитё_Отпуск_Лето_2008.jpg. А если категорий больше? Все категории в имя файла не запишешь.
А зачем категории писать в имя файла? Пишите в категории/ключевые_слова. В Windows на NTFS дисках с каждым файлом может быть ассоцииован скрытый поток с данными где, хранится вся эта расширенная информация — поиск умеет ее использовать.
Если у Вас нет паранойи, то это еще не значит, что они за Вами не следят.
Здравствуйте, alzt, Вы писали:
... A>>>Наверное, наиболее лучшим решением будет реализация с использованием тегов. ЮЖ>>Добавлю: нужны типизированные(числа, строки, даты) иерархические теги. Последние — это контейнеры + замена для "Литература/Техническая литература". "Литература" — это имя списка, а "Техническая" — одно из значений.
A>Да всё это нужно.
Это все есть =)
A>Судя по картинке да. Извиняюсь за безграмотность — что это? Уж не виста случайно ли?
Нет, это я в свободное время изобретаю.
A>Важно ещё лёгкость добавления тэгов, или файлов к категориям.
Один из способов (контекстное меню для файла в explorer'e. названия только для примера):
A>Ещё должны автоматически добавляться те характеристики, которые можно втоматически добавить. Например, в примере выше можно автоматически получить название альбома и имя исполнителя.
Ммм... что значит получить? Список исполнителей на первой картинке — это список из всех существующих значений, которые извлечены из файлов. На второй картинке пользовательские пользовательские атрибуты.
Здравствуйте, alzt, Вы писали:
A>Не всегда понятно какая категория более общая. В примере выше — мне не нравится, что english — это более общая категория. Если я хочу посмотреть все книги по С++, то мне придётся искать в двух папках ("English/Литература/Программирование/C++/Страуструпп" и "Русский/Литература/Программирование/C++/Страуструпп") вместо одной "/Программирвоание/C++/Литература" (или "/Программирвоание/C++/Литература/Страуструпп", если хочется конкретного автора).
А вы полагаете что в тагировании не будет неудобств?
Я бы категорию English/Русский вообще не стал употреблять потому что такая категория несет почти нулевую смысловую нагрузку. Да и не вписывается в общую картину. Нужно создавать такие категории которые описывают какой-либо тип или вид. Программирование -- вид Литературы. С++ -- вид программирования. Книги Страуструпа -- тоже описывает некоторый вид.
Здравствуйте, TK, Вы писали:
S>>А такой пример. У меня есть папка с фотографиями. Имена фотографий сами пониманиете какие — img_1234.jpg. Как теперь мне найти все фотографии с моим дитём? Я конечно могу все фото с дитём положить в отдельную папку. И туда же попадут фото с разными событиями жизни — ДР, Отпуск, Дача и т.д. Как тогда найти все фото из Отпуска? Можно, конечно давать файлам имена, например, Дитё_Отпуск_Лето_2008.jpg. А если категорий больше? Все категории в имя файла не запишешь.
TK>А зачем категории писать в имя файла? Пишите в категории/ключевые_слова. В Windows на NTFS дисках с каждым файлом может быть ассоцииован скрытый поток с данными где, хранится вся эта расширенная информация — поиск умеет ее использовать.
Здравствуйте, TheOldMan, Вы писали:
A>>Не всегда понятно какая категория более общая. В примере выше — мне не нравится, что english — это более общая категория. Если я хочу посмотреть все книги по С++, то мне придётся искать в двух папках ("English/Литература/Программирование/C++/Страуструпп" и "Русский/Литература/Программирование/C++/Страуструпп") вместо одной "/Программирвоание/C++/Литература" (или "/Программирвоание/C++/Литература/Страуструпп", если хочется конкретного автора).
TOM>А вы полагаете что в тагировании не будет неудобств?
TOM>Я бы категорию English/Русский вообще не стал употреблять потому что такая категория несет почти нулевую смысловую нагрузку. Да и не вписывается в общую картину. Нужно создавать такие категории которые описывают какой-либо тип или вид. Программирование -- вид Литературы. С++ -- вид программирования. Книги Страуструпа -- тоже описывает некоторый вид.
Есть у меня небольшая библиотека заготовок основ языка. Обычно создаю при изучении. То есть мини пример какой-либо фичи языка. Это уже не литература, но ещё С++.
Сейчас у меня на диске примерно половина файлов находятся в папках вида: "Новое", "Отсортировать", "Не сортированное", "Возможно удалить". Когда сортирую, часто есть проблемы с нахождением точного пути, куда файл нужно положить, т.к. не всегда понятно к чему именно можно его отнести. Тэги частично решат эту проблему — в этом случае я могу навесить на файл столько тэгов, сколько мне хочется.
Здравствуйте, Юрий Жмеренецкий, Вы писали:
A>>Ещё должны автоматически добавляться те характеристики, которые можно втоматически добавить. Например, в примере выше можно автоматически получить название альбома и имя исполнителя.
ЮЖ>Ммм... что значит получить? Список исполнителей на первой картинке — это список из всех существующих значений, которые извлечены из файлов. На второй картинке пользовательские пользовательские атрибуты.
Я имел ввиду, что, например, в формате mp3 содержится информация об исполнителе, жанре, название песни. Её не сложно извлечь автоматически и пользователь не должен сам в ручную её вводить.
ЮЖ>Если есть желание, могу подробнее рассказать.
Здравствуйте, alzt, Вы писали:
A>Я имел ввиду, что, например, в формате mp3 содержится информация об исполнителе, жанре, название песни. Её не сложно извлечь автоматически и пользователь не должен сам в ручную её вводить.
в формате содержится лишь возможность эту информацию указать. что реально там написано — большой вопрос.
Здравствуйте, Юрий Жмеренецкий, Вы писали:
A>>Судя по картинке да. Извиняюсь за безграмотность — что это? Уж не виста случайно ли? ЮЖ>Нет, это я в свободное время изобретаю.
A>>Важно ещё лёгкость добавления тэгов, или файлов к категориям. ЮЖ>Один из способов (контекстное меню для файла в explorer'e. названия только для примера):
ЮЖ>
Выглядит хорошо и очень похоже на то, что как раз нужно.
А как можно попробовать?
Здравствуйте, alzt, Вы писали:
A>Древовидная файловая система имеет некоторые ограничения: имеется 1 корень (или несколько, как в windows), в каждом каталоге могут содержаться ...
На самом деле это ИМХО от неверного толкования предназначения файловой системы. Она не для поиска нужных файлов, а для их хранения. Хранение подразумевает также и идентификацию отдельных файлов. Отказавшись от иерархии ты останешься только с именами файлов. Как избегать конфликтов? Или вообще отказаться от имен файлов оставить только теги? Как под это перенести всю накопившуюся практику работы? Как скомпилировать c++ программу в таком окружении?
ИМХО храним файлы в файловой системе. Каталогизируем их с помощью специальных для этого предназначенных систем.
Здравствуйте, swined, Вы писали:
A>>Я имел ввиду, что, например, в формате mp3 содержится информация об исполнителе, жанре, название песни. Её не сложно извлечь автоматически и пользователь не должен сам в ручную её вводить.
S>в формате содержится лишь возможность эту информацию указать. что реально там написано — большой вопрос.
Это я знаю. В моих файлах эта информация корректна как минимум в половине случаев.
Не припомню, чтобы было указано не правильно. Обычно либо написано что-то правильное или не написано вообще. Правда бывают орфографические ошибки и варианты с названием на разных языках.
РМ>ИМХО храним файлы в файловой системе. Каталогизируем их с помощью специальных для этого предназначенных систем.
Не понял, а что мешает взять NTFS и тупо добавить поддержку тегов? Даже не NTFS, а fastfat можно взять (благо он в исходниках) и переписать с поддержкой тегов. Т.е. просто маленькую фичу добавить и всё.
Здравствуйте, Рома Мик, Вы писали:
A>>Древовидная файловая система имеет некоторые ограничения: имеется 1 корень (или несколько, как в windows), в каждом каталоге могут содержаться ... РМ>На самом деле это ИМХО от неверного толкования предназначения файловой системы. Она не для поиска нужных файлов, а для их хранения. Хранение подразумевает также и идентификацию отдельных файлов. Отказавшись от иерархии ты останешься только с именами файлов. Как избегать конфликтов? Или вообще отказаться от имен файлов оставить только теги? Как под это перенести всю накопившуюся практику работы? Как скомпилировать c++ программу в таком окружении?
РМ>ИМХО храним файлы в файловой системе. Каталогизируем их с помощью специальных для этого предназначенных систем.
Да. Это в общем и требуется. Файловая система сейчас слишком нужна для поиска. В идеале сократить её до минимума (по физическим носителям). Оставить возможность как-то группировать файлы, но такая возможность будет просто никому не нужна.
С именами файлов не вижу никаких конфликтов. Просто добавлять индексы 1,2, 3007 в конец файла. Эти индексы даже не обязательно отображать для пользователя.
Сейчас аналогично, каталог может содержать несколько файлов с одним именем, но разными расширениями. Файловые менеджеры могут не показывать расширения. Сложностей не возникает.
Здравствуйте, x64, Вы писали:
A>>Хочется хорошей интеграции с существующими программами. A>>То есть, например, сделать фильтр по направлению музыки и добавить это всё в список воспроизведения.
x64>Если я правильно понял, то ты хочешь, чтобы дерево папок выглядело как-то так:
x64>
x64>Music
x64> Tags
x64> Rock
x64> Band 1
x64> Band 2
x64> Band 3
x64> Blues
x64> Band 2
x64> Band 3
x64> Pop
x64> Band 1
x64> Band 2
x64> Country
x64> Band 1
x64> Band 2
x64> Reggae
x64> Band 2
x64> Dance
x64> Band 3
x64> Club
x64> Band 1
x64> Techno
x64> Band 1
x64>
Почти. Я хочу вообще обходиться без иерархической структуры.
Это всё реализация. Не вижу смысла использовать файловую структуру для поддержки системы. Можно всё хранить отдельно.
x64>По поводу того, откуда взять список исполнителей для каждого тега. Ну тут можно какое-нибудь своё хранилище на C# напедалить, делов-то, типа своя мини-БД. Чтобы создать такую базу, скачай где-нибудь код на C#, выдирающий значение поля "Жанр" из MP3-тегов и накатай на коленке утилитку, которая будет обрабатывать все музыкальные файлы, которые ты хочешь запихнуть в эту мини-БД. При каждом запросе на шаге 4 будешь отправлять запрос к своей базе. Ну в общем, база — это чисто твоя забота, т.е. в колбеке тебя спрашивают "что отобразить в папке?", — ты возвращаешь список, всё просто. Единственный недостаток у этого движка — на больших объёмах (большое кол-во элементов в папке) начинает тормозить, т.к. всё взаимодействие с драйвером идёт через службу, а со службой через пайпы, и получается не оптимально. Ну зато бесплатно и с исходниками.
Скорость критична. Мне это нужно не для музыки, а вообще для всего. То есть объёмы будут довольно большие — все файлы.
Не всё так просто. Это будет основной способ поиска\хранения файлов. Соответственно не должно быть проблем при переустановке системы, должно легко работать слияние нескольких дисков. В базу данных не хочется запихивать. Сколько на это времени уйдёт?
x64>Собственно, второй вариант это написать драйвер-фильтр файловой системы. Это на порядок сложнее, но зато оптимально, производительно и highly-customizable. Если реально надо всё это — могу написать, но не забесплатно, разумеется. Вон там внизу по ветке человеку тоже нужно, ну скиньтесь тогда что ли, если дорого. Найдёте альтернативу — дайте знать, интересно будет взглянуть.
Это нужно. Но не настолько, чтобы отдавать кучу денег за это. Я думаю, что затраты здесь значительно больше, чем 1 человеко-месяц. Тем более учитывая, что идея до конца не сформулированна.
Здравствуйте, alzt, Вы писали:
A>>>Древовидная файловая система имеет некоторые ограничения: имеется 1 корень (или несколько, как в windows), в каждом каталоге могут содержаться ... РМ>>На самом деле это ИМХО от неверного толкования предназначения файловой системы. Она не для поиска нужных файлов, а для их хранения. Хранение подразумевает также и идентификацию отдельных файлов. Отказавшись от иерархии ты останешься только с именами файлов. Как избегать конфликтов? Или вообще отказаться от имен файлов оставить только теги? Как под это перенести всю накопившуюся практику работы? Как скомпилировать c++ программу в таком окружении?
РМ>>ИМХО храним файлы в файловой системе. Каталогизируем их с помощью специальных для этого предназначенных систем.
A>Да. Это в общем и требуется. Файловая система сейчас слишком нужна для поиска. В идеале сократить её до минимума (по физическим носителям). Оставить возможность как-то группировать файлы, но такая возможность будет просто никому не нужна.
Она может быть и не будет нужна с точки зрения пользователя. А многим она и не нужна, недаром в windows сделали папку "Мои документы" куда предлагается всё сваливать в кучу, что очень многие и делают. А вот с точки зрения системы очень даже нужна, потому что надо как-то отличать файлы относящиеся к разным сущностям: здесь у нас файлы пользователя (а кстати только им и нужна система тегов, остальным вообще не нужна), а здесь файлы программы А, здесь файлы программы Б, здесь драйвера.
На самом деле и правда можно сделать файловую систему с тегами и просто ввести еще теги для эмуляции иерархической файловой системы
A>С именами файлов не вижу никаких конфликтов. Просто добавлять индексы 1,2, 3007 в конец файла. Эти индексы даже не обязательно отображать для пользователя.
ИМХО индексы к именам файлов — это уж как-то совсем нехорошо.
A>Сейчас аналогично, каталог может содержать несколько файлов с одним именем, но разными расширениями. Файловые менеджеры могут не показывать расширения. Сложностей не возникает.
У кого как. У меня регулярно возникают. Вот есть некая программа, она может загружать внешние данные из xls файлов, причем есть еще файлы настроек этой загрузки, в которых описано из каких полей чего куда брать. Эти файлы имеют расширение dat. В принципе схема работы такая: берем данные вставляем в xls файл. В программе выбираем dat файл (в котором среди прочего указано уже и имя xls файла) и загружаем. У меня эти два файла имеют одинковое название и отличаются только расширением, например "загрузка сделок.xls" и "загрузка сделок.dat". Всё замечательно, пока не надо кого-то научить этим пользоваться, вопрос какой из двух файлов выбрать возникает регулярно.
Здравствуйте, Рома Мик, Вы писали:
A>>Да. Это в общем и требуется. Файловая система сейчас слишком нужна для поиска. В идеале сократить её до минимума (по физическим носителям). Оставить возможность как-то группировать файлы, но такая возможность будет просто никому не нужна. РМ>Она может быть и не будет нужна с точки зрения пользователя. А многим она и не нужна, недаром в windows сделали папку "Мои документы" куда предлагается всё сваливать в кучу, что очень многие и делают. А вот с точки зрения системы очень даже нужна, потому что надо как-то отличать файлы относящиеся к разным сущностям: здесь у нас файлы пользователя (а кстати только им и нужна система тегов, остальным вообще не нужна), а здесь файлы программы А, здесь файлы программы Б, здесь драйвера.
Я описываю только пользовательские данные. Служебные пользователь вообще трогать не должен (кроме конфигурационных).
A>>Сейчас аналогично, каталог может содержать несколько файлов с одним именем, но разными расширениями. Файловые менеджеры могут не показывать расширения. Сложностей не возникает. РМ>У кого как. У меня регулярно возникают. Вот есть некая программа, она может загружать внешние данные из xls файлов, причем есть еще файлы настроек этой загрузки, в которых описано из каких полей чего куда брать. Эти файлы имеют расширение dat. В принципе схема работы такая: берем данные вставляем в xls файл. В программе выбираем dat файл (в котором среди прочего указано уже и имя xls файла) и загружаем. У меня эти два файла имеют одинковое название и отличаются только расширением, например "загрузка сделок.xls" и "загрузка сделок.dat". Всё замечательно, пока не надо кого-то научить этим пользоваться, вопрос какой из двух файлов выбрать возникает регулярно.
Так я же для себя описываю, что мне надо. Может кому-то и неудобно будет.
Фактически, расширение это и есть некоторый тэг, который есть у файла. Нужна возможность добавлять больше.
Как показывает практика, начиная с некоторого объема информации тэги становятся бесполезны. Трудозатраты на их постановку не компенсируются легкостью поиска.
Лица на фотках распознавать кстати говорят умеет пикаса.
Вообще, я тоже когда-то думал над этой идеей, но с ростом инета от юзкейса "храним все что нужно у себя" оказалось гораздо выгоднее хранить у себя только трудновосстанавливаемую информацию. В моем случае это: музыка, фотки, почта, хистори аськи, рабочие доки.
Реально тэги применять имеет смысл к музыке — ну так они есть в виде инфы в самом файле (хотя я например практически пользуюсь этим раз в месяц)
и к фото, но тут трудоемкость затэгировать одну-две сотни фоток раз в месяц гораздо сложнее, чем решить раз в жизни задачу "Все фотки с Васей".
Ну а все остальное(типа упоминаемых книг страуструпа) в случае необходимости довольно легко находиться в инете и скачивается.
A>Я хочу вообще обходиться без иерархической структуры.
Видишь ли в чём проблема. От иерархической структуры отказаться здесь и сейчас не получится по той простой причине, что вот тот же WinAmp или Windows Media Player просто физически ещё не умеют работать с какой-либо другой структурой (ты ведь хочешь использовать все привычные тебе программы, не так ли?). Потому на сегодняшний день я вижу только одно решение, состоящее из следующих компонентов:
1. Файловый фильтр.
2. Интерфейс для настройки.
Как это будет работать и как я себе это вижу. Иерархическую систему пока оставляем, т.к. без неё не будут работать наши привычные приложения. Добавляем специальную папку в корень каждого диска. Не сами вручную добавляем, — это будет делать фильтр автоматически. Назовём эту папку "Tags". Подпапки в ней — это теги. Теги можно назначать как файлам так и папкам. При чтении содержимого любой подпапки в Tags получим только те элементы, среди тегов которых есть строка, равная имени этой подпапки. Ну, тут думаю, всё очевидно. Информацию о тегах можно сохранять в файловых потоках (поиск по ним и формирование индекса — отдельный вопрос, надо подумать ещё), и тогда не будет проблем с переустановками системы. Единственное ограничение будет в том, что файлы можно будет перемещать/копировать на другой диск только при условии, что его файловая система тоже поддерживает потоки (ADS), в противном случае содержимое и атрибуты файла сохранятся, а теги нет. Я лично думаю, что это не критично, но если всё таки поддержка других ФС (например, FAT) важна, можно придумать другое решение, сейчас это не принципиально.
Итак, у нас есть папка "\Tags" и подпапки-теги внутри. Теперь, чтобы просмотреть все файлы, относящиеся к детям, достаточно открыть папку "\Tags\Дети". На мой взгляд этого недостаточно, потому что файлы обычно имеют ещё и тип, а мешать музыку, фотки и текстовые документы в кучу как-то не очень. Можно предусмотреть ещё один уровень вложенности типа "\Tags\<Tag>\<Type>", где <Type> — некий абстрактный тип, с которым ассоциированы несколько расширений, например "Изображения = (jpg, png, bmp, tif, gif, ...); Текст = (txt, doc, odt, ...); ...". На уровне файлового фильтра это сделать несложно, потребуется разве что дополнительно ещё один файл с этими настройками, где-нибудь в "\Tags\tagopt.dat". Короче, в итоге чтобы просмотреть все детские фотографии, достаточно будет открыть ACDSee в папке "\Tags\Дети\Фотографии". Вообще, все эти сортировки можно со временем, так сказать, "расширить и углубить", но пока для первой версии, думаю, достаточно будет предложенного выше.
Ну с первым компонентом, в общем, понятно. Это файловый фильтр, выполненный в виде драйвера-фильтра файловой системы. С поддержкой разных версий ОС здесь проблем нет, все версии от XP до 7, а также все аппаратные архитектуры, — легко. Пункт 2 необходим, потому что в Windows, разумеется, нет никаких средств для работы с этими тегами — она о них просто ничего не знает. Интерфейс можно реализовать в виде двух модулей — один WinForms-приложение на C#, взаимодействующее с фильтром с целью добавления информации о тегах к тем или иным объектам при помощи оконного интерфейса. Второе — расширение проводника (shell extension), добавляющее в контекстное меню каждого файлового объекта пункт типа "Set tags...".
Возможно, у кого-то есть другие идеи или замечания, только помните о том, что полностью отказаться от иерархической структуры на сегодняшний день нет никакой возможности.
A>Скорость критична. Мне это нужно не для музыки, а вообще для всего. То есть объёмы будут довольно большие — все файлы.
Ну я понял, см. выше. Придётся писать с нуля с использованием наработок (если есть).
A>Не всё так просто. Это будет основной способ поиска\хранения файлов. Соответственно не должно быть проблем при переустановке системы, должно легко работать слияние нескольких дисков.
Особых проблем не вижу.
A>В базу данных не хочется запихивать.
Ну вообще-то БД тебе всё равно придётся набивать самому. С использованием ли каких-то вспомогательных утилит или без оных, — но это всё равно надо будет сделать, ибо теги должен кто-то назначить файлам/папкам. А как ты хотел.
A>Сколько на это времени уйдёт?
Месяца 3 до первой более-менее рабочей беты.
A>Это нужно. Но не настолько, чтобы отдавать кучу денег за это. Я думаю, что затраты здесь значительно больше, чем 1 человеко-месяц. Тем более учитывая, что идея до конца не сформулированна.
Сроки примерные см. выше, идея в общих чертах уже есть и понимание как её реализовать — тоже. К тому же ты не один нуждающийся, значит есть возможность скинуться. Ну смотри сам, я никого уговаривать не буду, предложил только потому, что выполнить такую работу мне и самому было бы интересно.
Здравствуйте, alzt, Вы писали:
A>Добрый вечер.
... A>Теперь вопрос — есть ли что-либо подобное реализованное сейчас?
Для файловых систем возможно нет (не выяснял) но есть Evernote. С иерархическими тегами, сортировкой и сохраняемыми запросами. С возможностью делать аттачи к заметкам. С синхронизацией между устройствами. Большие файлы конечно там не сохранишь, но документы, заметки, ссылки и т.п. — вполне.
Здравствуйте, genre, Вы писали:
G>и к фото, но тут трудоемкость затэгировать одну-две сотни фоток раз в месяц гораздо сложнее, чем решить раз в жизни задачу "Все фотки с Васей".
См. фконтакте. Просто фотки надо там хранить и всё. (сам правда не пользуюсь и не планирую)
Здравствуйте, Рома Мик, Вы писали:
РМ>Здравствуйте, genre, Вы писали:
G>>и к фото, но тут трудоемкость затэгировать одну-две сотни фоток раз в месяц гораздо сложнее, чем решить раз в жизни задачу "Все фотки с Васей". РМ>См. фконтакте. Просто фотки надо там хранить и всё. (сам правда не пользуюсь и не планирую)
о_О странный выбор примера. а почему не пикаса или фликр?
Здравствуйте, Рома Мик, Вы писали:
G>>и к фото, но тут трудоемкость затэгировать одну-две сотни фоток раз в месяц гораздо сложнее, чем решить раз в жизни задачу "Все фотки с Васей". РМ>См. фконтакте. Просто фотки надо там хранить и всё. (сам правда не пользуюсь и не планирую)
Я, может, чего не понял, но отчего бы не пройти простым путем? Насоздавать ссылок во всех возможных подкаталогах и вперд? Ссылки могут быть либо жесткие, либо символические, по желанию.
Здравствуйте, Majestic, Вы писали:
РМ>>См. фконтакте. Просто фотки надо там хранить и всё. (сам правда не пользуюсь и не планирую) M>о_О странный выбор примера. а почему не пикаса или фликр?
Просто единственное, что видел своими глазами.
А почему нельзя хранить? Заливаешь туда, они там хранятся.
Здравствуйте, race1, Вы писали:
R>Было бы ну просто очень нереально круто если бы эта система тэгов/категорий работала на уровне файловой/операционной системы, что бы любая прога могла её использовать
Здравствуйте, genre, Вы писали:
R>>Было бы ну просто очень нереально круто если бы эта система тэгов/категорий работала на уровне файловой/операционной системы, что бы любая прога могла её использовать
G>а зачем? какие юзкейсы?
Для того что бы тэгированная информация обрабатывалась одинаково во всех программах, используя единое API.
Предположим такое уже есть — API на уровне ОС, позволяющее работать с тэгами (ключевыми словами)/категориями, и, скажем, Проводник это поддерживает:
— Я говорю что хочу посмотреть как я катался на велосипеде в этом году, выбираю соотв. тэги "велосипед", "race1", говорю "группировка по дате" и вижу список фоток где я катаюсь на велосипеде Это так, для начала, скажем что бы показать другу что велосипед это здорово
— У кого-то день рождения, я хочу сделать календарик с его фотами. Я выбираю тэг "мама" и вижу все фотки с мамой, выбираю лучшие фоты, делаю календарик
— Я хочу послушать какую-то группу, выбираю тэг "My Favorite Artist", говорю группировать по альбомам — получаю список альбомов/песен, добавляю в плей-лист, слушаю
При этом вся музыка у меня свалена в одной папке, все фоты — в другой (размеется имеет смысл поддерживать минимальный порядок), но мне нет до этого дела, потому что у меня есть тэги. Кроме того эта же штука будет работать и в фаре и тотал коммандере и где угодно вообще.
Древовидная же структура останется на месте, просто появится ещё один слой — слой тэгов.
Сейчас я всё это могу делать, но в разных программах. Для фоток — одна программа, для музыки — другая. Вот поэтому и было бы здорово единое API.
Здравствуйте, race1, Вы писали:
R>- Я говорю что хочу посмотреть как я катался на велосипеде в этом году, выбираю соотв. тэги "велосипед", "race1", говорю "группировка по дате" и вижу список фоток где я катаюсь на велосипеде Это так, для начала, скажем что бы показать другу что велосипед это здорово R>- У кого-то день рождения, я хочу сделать календарик с его фотами. Я выбираю тэг "мама" и вижу все фотки с мамой, выбираю лучшие фоты, делаю календарик
и сколько раз в твоей жизни тебе это требовалось? в моей ни разу.
ну я могу предположить, что может и понадобиться когда-нибудь, но городить систему тэгов для этого это сильный оверхед. я и так выберу лучшие фотки с мамой минут за 10. При том, что фоток у меня не одна тысяча.
R>- Я хочу послушать какую-то группу, выбираю тэг "My Favorite Artist", говорю группировать по альбомам — получаю список альбомов/песен, добавляю в плей-лист, слушаю
а с этим справляется файловая система
с музыкой правильный юзкейс выглядит так: хочу послушать какой-нибудь джаз
тут да, ты прав, но:
R>Сейчас я всё это могу делать, но в разных программах. Для фоток — одна программа, для музыки — другая. Вот поэтому и было бы здорово единое API.
я очень сомневаюсь в юзабилити такого решения
Здравствуйте, genre, Вы писали:
G>ну я могу предположить, что может и понадобиться когда-нибудь, но городить систему тэгов для этого это сильный оверхед. я и так выберу лучшие фотки с мамой минут за 10. При том, что фоток у меня не одна тысяча.
С мамой найдёшь, ладно. А с Василием Пупкиным, которого последний раз видел и фотал 10 лет назад и надо сделать календарик? Утрирую, конечно, но разбираться в 10-х тысяч фоток всё-же думаю удобнее с тэгами. Для меня назначить тэги совсем несложно, при том что это будет сделано один раз. Ну потратишь один раз при скидывании фоток с фотоаппарата пол часа. Зато сэкономишь кучу времени когда надо будет сделать выборку.
R>>- Я хочу послушать какую-то группу, выбираю тэг "My Favorite Artist", говорю группировать по альбомам — получаю список альбомов/песен, добавляю в плей-лист, слушаю G>а с этим справляется файловая система G>с музыкой правильный юзкейс выглядит так: хочу послушать какой-нибудь джаз
Можно сделать выборку по жанру
G>тут да, ты прав, но:
R>>Сейчас я всё это могу делать, но в разных программах. Для фоток — одна программа, для музыки — другая. Вот поэтому и было бы здорово единое API. G>я очень сомневаюсь в юзабилити такого решения
Смотря как это будет реализовано. Плюс не надо думать о тэгах как о какой-то неизбежности. Тэги — дополнительный слой над обычной древовидной структурой.
В общем я бы с удовольствием баловался с тэгами применительно к каким-то данным, если бы была возможность. Думаю нашлись бы ещё такие же как я. А кто-то бы не пользовался бы. Свобода выбора
Здравствуйте, Рома Мик, Вы писали:
РМ>А почему нельзя хранить? Заливаешь туда, они там хранятся.
Потому что вконтакте (как впрочем и большинство подобных сервисов) хранят не оригинал, а пожатую до невозможности копию.
Оригиналы можно хранить например на яндекс фотках.
Ну а у меня оригинал это вообще не jpg а raw файл, такие вообще никто не хранит
Здравствуйте, race1, Вы писали:
R>С мамой найдёшь, ладно. А с Василием Пупкиным, которого последний раз видел и фотал 10 лет назад и надо сделать календарик? Утрирую, конечно, но разбираться в 10-х тысяч фоток всё-же думаю удобнее с тэгами. Для меня назначить тэги совсем несложно, при том что это будет сделано один раз. Ну потратишь один раз при скидывании фоток с фотоаппарата пол часа. Зато сэкономишь кучу времени когда надо будет сделать выборку.
Ты пробовал это делать? Я — да. Несколько лет назад когда я купил цифровую камеру я решил, что буду аккуратно вести систему тегов.
Сломался я на третей сотне кадров.
А вот надобности в реальной жизни в этой системе так не разу и не возникло. А даже бы если и возникло, то затраты на простановку тэгов бы не окупились.
Другое дело, что как только научаться проставлять тэги автоматом, то будет интересно, но даже тогда тэги будут просто подпоркой невозможности вменяемого поиска по картинкам и музыке.
Здравствуйте, genre, Вы писали:
G>Ты пробовал это делать? Я — да. Несколько лет назад когда я купил цифровую камеру я решил, что буду аккуратно вести систему тегов. G>Сломался я на третей сотне кадров. G>А вот надобности в реальной жизни в этой системе так не разу и не возникло. А даже бы если и возникло, то затраты на простановку тэгов бы не окупились.
~15 тысяч. Не все мои, не все представляют большую ценность, но почти все с тегами. Это ещё зависит от того, как вести...
G>Другое дело, что как только научаться проставлять тэги автоматом, то будет интересно, но даже тогда тэги будут просто подпоркой невозможности вменяемого поиска по картинкам и музыке.
Пусть так, но тэги таки дают преимущество над древовидной структурой?
Здравствуйте, race1, Вы писали:
R>Плюс папка с музыкой тоже добавлена в медиабиблиотеку в фубаре, так же очень просто можно делать различные выборки не задумываясь где музыка есть на самом деле.
Кстати. Я тоже так делал. А потом вернулся обратно к файловой системе. Знаешь почему? У меня фубар жестко тормозил при фильтрации по имени исполнителя
Здравствуйте, genre, Вы писали:
R>>~15 тысяч. Не все мои, не все представляют большую ценность, но почти все с тегами. Это ещё зависит от того, как вести... G>А ты можешь хотя бы на глаз прикинуть сколько времени на это ушло и сколько раз и в каких ситуациях это пригодилось?
Времени действительно ушло прилично, я запарился теги расставлять Пригодилось? Наверное пригодилось, часто смотрю по тегам.
R>>Плюс папка с музыкой тоже добавлена в медиабиблиотеку в фубаре, так же очень просто можно делать различные выборки не задумываясь где музыка есть на самом деле.
G>Кстати. Я тоже так делал. А потом вернулся обратно к файловой системе. Знаешь почему? У меня фубар жестко тормозил при фильтрации по имени исполнителя
Ого! А сколько там было музыки? У меня ~7000, подтормаживает, но терпимо.
Здравствуйте, race1, Вы писали:
R>Времени действительно ушло прилично, я запарился теги расставлять Пригодилось? Наверное пригодилось, часто смотрю по тегам.
Во-во!
Ты по тегам смотришь именно так, как не справляется файловая система?
У меня все фотки разложены по папкам "дата — Пьянка у Пети"/"дата — Пьянка у Васи"/"дата — Свиданка с Машей"/....
покрывает 99,9% потребностей.
то что не покрывается делается ручками минут за 5. Такого чтобы я искал нужные мне фотки долго не было ни разу.
R>Ого! А сколько там было музыки? У меня ~7000, подтормаживает, но терпимо.
В песнях не знаю. Намного больше 7000.
Это примерно терабайт мп3шек.
Здравствуйте, x64, Вы писали:
RO>>Сделано-то уже давно — Logic File System.
x64>Не, не, "сделано" — это когда под Windows, а это так... "студенты баловались".
Не снисходя до рассмотрения самого утверждения, обращу твое внимание на то, что на вышеупомянутой странице, а равно и по ссылкам, не упоминается ни одна конкретная ОС.
Заинтересовала ваша дискуссия , по той причине , что у меня есть программка , которая добавляет описания к файлам
и я давно думал добавить туда теги , но считал , что в этом нет необходимости .
На прогу давно забил , ввиду ее непокупаемости , но могу подергаться в плане добавления тегов , если у кого то есть интерес.
В связи с этим вопрос — есть два варианта сортировки по тегам —
один в виде виртуальной папки
второй в виде дополнительного интерфейса к программе
Какой был бы предпочтительней для вас ?
Саму прогу можно посмотреть — www.akslab.com userinfotip
вторую не смотрите шоп я не позорился ... оставил ее для того чтоб просто что то еще на странице было.
к тому же — если есть какие то замечания предложения по существующей — вэлком.
естественно если нужен ключ — то тоже вэлком ... вообще ее хочу во фривару отправить чтоб хоть не деньги так польза была
... хотя наверное мой единственный покупатель расстроиться
Здравствуйте, TheOldMan, Вы писали:
TOM>Вообщем, используя категоризацию мне ненужны: теги, google desktop и очень редко использую поиск.
Тут есть такая проблема, что иерархию нужно проектировать и рефакторить при изменении требований. При этом, чтобюы проектировать надо заранее знать под какие задачи. А иначе иерархия легко затрудняет поиск, вместо того, чтобы его облегчить. Например, если ты ищешь в тематическом каталоге книги определённого автора, или издателя, или объёма и т. д., то тематический каталог тебе только мешает...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, Erop, Вы писали:
E>Здравствуйте, alzt, Вы писали:
A>>Теперь вопрос — есть ли что-либо подобное реализованное сейчас?
E>По идее было бы круто иметь какой-то всеми разделяемый способ прикреплять к файлу xml'ку с описанием.
тут проблема с перемещением файла , описание теряется если перемещать в другой каталог , но экспорт можно сделать
E>Дальше можно было бы E>1) Индексировать и искать по этим описалкам
очень плохо ( с точки зрения разработчика ) в этом плане сделали в висте , крайне неудобно и сложно ( хотя возможно )
интегрироваться с индексированием самого эксплорера ... плохо что невозможно назначить обработчик , скажем для ключевых слов ,
для всех типов файлов , или несколько обработчиков для одного типа ... а так былобы неплохо
E>2) Иметь редакторы таких описалок для каких-то специфических случаев, скажем для закачки с фотика, для музыки, для файла из торрента и т. д.
это уже кастомизэйшин — но интересно
E>3) Иметь описалки не только на файл но и на каталог.
эт есть
E>Ну и как-то среди этого всего искать.
E>Как искать -- вопрос отдельный. Мне нравится тутошнее предложение иметь виртуальный диск, папки в котором -- это иерархические запросы. E>Типа будет легко из любой проги сделать запрос, уточнить его, и т. д...
т.е. таки виртуальная папка интересней , чем самописный UI ?
зы ... наверно подоживлю проект ... вдруг че и зашевелиться
Здравствуйте, alzt, Вы писали:
... ЮЖ>>Если есть желание, могу подробнее рассказать.
A>Желание есть.
Если коротко, то сделано примерно так:
*) Теги (атрибуты) — типизированные значения. Строки, даты, числа, bool'ы. Это простые, скалярные величины. Помими них есть агрегатные типы — списки, контейнеры и диапазоны. Список может содержать значения одного типа, например список строк. У списков есть такая характеристика, как максимальное количество значений. Но не в самом списке, а "присвоенных" значений. Визуально это эквивалентно radiobutton vs checkboxes. Контейнеры — служат для организации иерархий из других атрибутов. Диапазоны — это обособленный тип, используемый в вычислениях.
*) Сами по себе атрибуты (точнее их значения) вторичны, первичной является схема атрибутов. Это практически эквивалент схем, используемых в xml. Схема атрибутов описывает иерархиию атрибутов, например (схематично):
Файл не может иметь атрибутов, которые не присутствуют в схеме. Т.е. [File].[Name] — допустимо, а [File].[Blablabla] — нет. Без этого ограничения невозожно обеспечить приемлимую производительность (в рамках выбранного подхода), и крайне трудно реализовать удобный UI.
Некоторые куски схемы создаются плагинами, которые извлекают данные, + можно добавлять пользовательские атрибуты по своему желанию.
*) Workspace (Store в WinFS) — логическая абстракция набора файлов, связанных (опционально) любыми критериями. 'Музыка', 'Документы', etc.
В workspace хранится схема атрибутов, ссылки на файлы(пути), атрибуты присвоенные файлам, и еще некоторые вещи. Перед тем как файлу можно будет присваивать атрибуты, его необходимо "добавить" в workspace. При этом произойдет автоматическое извлечение всех возможных атрибутов (плагинами).
*) virtual filesystem — тут все просто — можно создавать папки, какждая из которых имеет фильтр — специальный запрос-предикат на скриптовом языке. При открытии папки происходит вычисление значения этого предиката для каждого файла (не так прямолинейно конечно) и если результат равен 'true' — то файл отображается, иначе нет.
*) простой язык запросов — используется для
а) написания фильтров — примеры
true -- все файлы
false -- ни одного файла
[Image].[Width] = 1024 and [Image].[Height] = 768 - картинки с разрешением 1024 на 768
DateDiff(Now(), [File].[Added], "d") < N - файлы, добавленные за последние N дней
[File].[Name] = "Readme.txt" -- так тоже можно, в папке могут отображаются файлы с одинаковыми именами
[Music].[Genre] = "jazz" -- "хочу послушать какой-нибудь джаз"
и т.п.
б) для вычисляемых колонок в Detalis view.
в) для генерации имен при переименовании файлов.
~ 30 функций, операторы, и т.п.
*) интеграция в windows explorer. copy/paste в обе стороны. Виртуальные папки можно копировать на диск — при этом копируются все файлы, содержащиесы в них. Схема атрибутов отображается на context menu (на картинке в моем предыдущем ответе).
*) генерация иерархий папок. Указываем правила формирования уровней — можно просто атрибуты, можно любые выражения. Нажимаем "поехали", получается следующее:
Генерация происходит по имеющимся атрибутам. Сверху на картинке показано что мы указали для каждого уровня ([Music].[Artist],..), внизу — получившаяся иерархия. Каждой папке автоматом назначается соответствующий фильтр. Процесс настраиваемый, там можно еще кое-что подкрутить.
---
минусы — сначал непривычен тот факт, что файлы нельзя мышой таскать по папкам. Только так: изменил атрибуты — файлы сами появились/исчезли в соответствующих папках.
По поводу интеграции с существующими приложеними — тут плохо. Содержимое папок можно получить с помощью shell api, но так практически никто не делает.
Drag'n'Drop впрочем работает.
Здравствуйте, x64, Вы писали:
... A>>Не всё так просто. Это будет основной способ поиска\хранения файлов. Соответственно не должно быть проблем при переустановке системы, должно легко работать слияние нескольких дисков.
x64>Особых проблем не вижу.
Есть така проблема: делаем файлу "Set tags...", через неделю этот файл перемещаем в другую папку или меняем имя. Как отслуживать такие вещи? Мониторить в драйвере все файловые операции?
Здравствуйте, Erop, Вы писали:
E> A>Теперь вопрос — есть ли что-либо подобное реализованное сейчас?
E> По идее было бы круто иметь какой-то всеми разделяемый способ прикреплять к файлу xml'ку с описанием. Типа там должно быть основное поле "неформальное описание файла", возможно можно иметь описания на разных языках + какие-то переменные.
E> Дальше можно было бы E> 1) Индексировать и искать по этим описалкам E> 2) Иметь редакторы таких описалок для каких-то специфических случаев, скажем для закачки с фотика, для музыки, для файла из торрента и т. д. E> 3) Иметь описалки не только на файл но и на каталог.
E> Ну и как-то среди этого всего искать.
E> Как искать -- вопрос отдельный. Мне нравится тутошнее предложение иметь виртуальный диск, папки в котором -- это иерархические запросы. E> Типа будет легко из любой проги сделать запрос, уточнить его, и т. д...
Добро пожаловать в MacOS X
Помимо мегакрутого spotlight'а, который и так уже ищт все, что надо и не надо, к каждому файлу и папке можно оставить так называемые spotlight comments, которые будут индексироваться и учитываться при поиске. Не говоря уже о том, что разработчики могут свои файлы снабжать большим кол-вом метаинформации для поиска:
a> Предположим, появляется у меня файл "Evolution_C++.txt" я навешиваю на него теги: "С++", "Русский язык", "Литература", "Литература/Техническая литература", "Читал", "Программирование". Затем, когда я хочу найти эту книгу, я делаю запрос (или фильтр) "Литература", после чего выбираю подтему "Техническая литература". Затем мне предлагается набор файлов, которые подходят под этот запрос, а также список тэгов, с которыми встречается текущий тег. Среди них я выбираю "С++" и поиск уже сильно сужается — я могу найти нужный мне файл.
Это неудобно. Если ты знаешь, что файл назывался Ecolution_C++, то именно по этому названию ты его и будешь искать. С тэгами может справится редактируемый и индексируемый комментарий к файлу: http://www.rsdn.ru/forum/message/3390044.aspx
Здравствуйте, Юрий Жмеренецкий, Вы писали:
ЮЖ>... A>>Выглядит хорошо и очень похоже на то, что как раз нужно. A>>А как можно попробовать?
ЮЖ>Пока никак. Как до релиза доберусь, сообщу.
ЮЖ>Есть така проблема: делаем файлу "Set tags...", через неделю этот файл перемещаем в другую папку или меняем имя. Как отслуживать такие вещи? Мониторить в драйвере все файловые операции?
Здравствуйте, Юрий Жмеренецкий, Вы писали:
ЮЖ>*) virtual filesystem — тут все просто — можно создавать папки, какждая из которых имеет фильтр — специальный запрос-предикат на скриптовом языке. При открытии папки происходит вычисление значения этого предиката для каждого файла (не так прямолинейно конечно) и если результат равен 'true' — то файл отображается, иначе нет.
Это даже больше, чем мне требуется.
Достаточно просто запоминать список запросов и возможность их сохранять.
ЮЖ>*) простой язык запросов — используется для ЮЖ> а) написания фильтров — примеры ЮЖ>
ЮЖ> true -- все файлы
ЮЖ> false -- ни одного файла
ЮЖ> [Image].[Width] = 1024 and [Image].[Height] = 768 - картинки с разрешением 1024 на 768
ЮЖ> DateDiff(Now(), [File].[Added], "d") < N - файлы, добавленные за последние N дней
ЮЖ> [File].[Name] = "Readme.txt" -- так тоже можно, в папке могут отображаются файлы с одинаковыми именами
ЮЖ> [Music].[Genre] = "jazz" -- "хочу послушать какой-нибудь джаз"
ЮЖ> и т.п.
ЮЖ>
Для удобства всё равно нужен GUI, даже если язык простой.
ЮЖ>По поводу интеграции с существующими приложеними — тут плохо. Содержимое папок можно получить с помощью shell api, но так практически никто не делает. ЮЖ>Drag'n'Drop впрочем работает.
Можно вместо перетаскивания сделать создания ярлыков и их перемещение во временную папку. Тогда операция много времени не должна занять.
Здравствуйте, Mamut, Вы писали:
M>Добро пожаловать в MacOS X
Я знаю, как это в MAC OS. К сожалению, существование ftp всё портит...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, carpenter, Вы писали:
C>Здравствуйте, Юрий Жмеренецкий, Вы писали:
ЮЖ>>Есть така проблема: делаем файлу "Set tags...", через неделю этот файл перемещаем в другую папку или меняем имя. Как отслуживать такие вещи? Мониторить в драйвере все файловые операции?
C>дополнительные потоки
Здравствуйте, alzt, Вы писали:
... A>Для удобства всё равно нужен GUI, даже если язык простой.
На первой картинке Expression Editor. В нем очень просто создавать фильтры такого вида — [Music].[Genre] = "jazz". + там же есть список произвольных, список функций и операторов. Как можно сделать еще удобней? у меня пока мыслей нет.
"true/false" вынесены к контекстное меню папки, надо будет туда же и список произвольных/последних используемых вытащить.
ЮЖ>>По поводу интеграции с существующими приложеними — тут плохо. Содержимое папок можно получить с помощью shell api, но так практически никто не делает. ЮЖ>>Drag'n'Drop впрочем работает.
A>Можно вместо перетаскивания сделать создания ярлыков и их перемещение во временную папку.
Хм. А зачем? Перетаскивание — это в первую очередь для таскания файлов в приложения, в тот же Винамп.
Во вторую — для получения структуры папок на диске. Т.е. сначала создаем иерархию папок в "красивом" виде, потом копируем ее на диск с всем содержимым.
Здравствуйте, Юрий Жмеренецкий, Вы писали:
ЮЖ>Здравствуйте, carpenter, Вы писали:
C>>Здравствуйте, Юрий Жмеренецкий, Вы писали:
ЮЖ>>>Есть така проблема: делаем файлу "Set tags...", через неделю этот файл перемещаем в другую папку или меняем имя. Как отслуживать такие вещи? Мониторить в драйвере все файловые операции?
C>>дополнительные потоки
ЮЖ>Ага, это решение уже предлагали, я его пропустил.
к стати в ХР был более менее документированный формат дополнительного потока для задания аттрибутов файла ,
что давало возможность плотно работать с самим эксплорером .
в дурацкой висте это все переделали семерка соответственно
к стати в семерке теперь для отображения папок используеться не старый добрый листвью а какойто проприетарный
толи directview то ли чтото похожее ( на памать не вспомню)
документации по нему не нашел
C>В связи с этим вопрос — есть два варианта сортировки по тегам - C>один в виде виртуальной папки C>второй в виде дополнительного интерфейса к программе C>Какой был бы предпочтительней для вас ?
Глядя на скриншоты я не увидил никаких тегов или категорий. Только описание файла.
Это ещё не реализовано или скриншоты такие?
Насчёт предпочительного способа сложно сказать, трудно определиться ни разу не попробовать.
Скорее всего виртуальные папки, но всё зависит от многих деталей (особенно скорости работы).
ЮЖ>>>Есть така проблема: делаем файлу "Set tags...", через неделю этот файл перемещаем в другую папку или меняем имя. Как отслуживать такие вещи? Мониторить в драйвере все файловые операции? C>>дополнительные потоки ЮЖ>Ага, это решение уже предлагали, я его пропустил.
Да, на самом деле файловые потоки (file streams) — это хорошее универсальное решение, но у него есть два недостатка:
1. При копирования файла на ФС, которая не поддерживает потоки, последние просто теряются.
2. При копировании файла вручную без использования системных функций вроде CopyFile, файловые потоки не копируются.
Оба эти недостатка представляются лично мне несущественными и бороться с ними не вижу причин.
ЮЖ>По поводу интеграции с существующими приложеними — тут плохо.
Угу, потому что надо писать как и положено — файловый фильтр на уровне ядра, а не заниматься самодеятельностью в Shell API, которым практически никто не пользуется, кроме самой Shell.
Здравствуйте, x64, Вы писали:
ЮЖ>>>>Есть така проблема: делаем файлу "Set tags...", через неделю этот файл перемещаем в другую папку или меняем имя. Как отслуживать такие вещи? Мониторить в драйвере все файловые операции? C>>>дополнительные потоки ЮЖ>>Ага, это решение уже предлагали, я его пропустил.
x64>Да, на самом деле файловые потоки (file streams) — это хорошее универсальное решение, но у него есть два недостатка:
x64>1. При копирования файла на ФС, которая не поддерживает потоки, последние просто теряются. x64>2. При копировании файла вручную без использования системных функций вроде CopyFile, файловые потоки не копируются.
x64>Оба эти недостатка представляются лично мне несущественными и бороться с ними не вижу причин.
еще обжатие ... но рар поддерживает сохранение потоков в архив ( что частично решает первую проблему )
E>Как искать -- вопрос отдельный. Мне нравится тутошнее предложение иметь виртуальный диск, папки в котором -- это иерархические запросы. E>Типа будет легко из любой проги сделать запрос, уточнить его, и т. д...
Да, я примерно так это и вижу. Эх, там столько всего можно было бы наворотить, жаль заказа на это нету. Было б свободное время — написал бы и за так, да где ж его взять-то, это время...
Здравствуйте, x64, Вы писали:
ЮЖ>>По поводу интеграции с существующими приложеними — тут плохо.
x64>Угу, потому что надо писать как и положено — файловый фильтр на уровне ядра, а не заниматься самодеятельностью в Shell API, которым практически никто не пользуется, кроме самой Shell.
Tortoise SVN, Gmail drive, и т.п., Блокнот, который умеет открывать файл "Мой компьютер/Мой документы/123.txt"... но я не о том хочу сказать. Вот чем пользуются пользователи. Они _вообще_ незнают про Shell API. Им все равно — драйвер это или нет. Можно с помощью NSE выставить папки в локальную сеть?(нет) Можно с помощью драйвера получить несколько файлов с одинаковыми именами в одной папке?(я не знаю правильного ответа, но что-то мне подсказывает, что нет). Каждой вещи найдется свое применение, почему ты так противопоставляешь драйверы всему остальному — для меня загадка =)
С NSE пока только одно реальное неудобство — просмотр картинок (это все про кнопочку Next, или как она там) в папке с помощью того же ACDSee (в эксплорере, как вариант есть режим View/Filmstrip, но про его существование мало кто знает). Кстати, с помощью той же ACDSee можно было бы вполне легко просматривать (опять про кнопочку Next) картинки, не имеющие физического пути (аттачи в почте, например) Нет, ей нужны реальные файлы, реальные папки. Я тоже могу назвать это самодеятельностью. Где я не прав?
Имхо, все программы, работающие с файлами (исключая специфические), должны принимать на вход некий абстрактный интерфейс иерархичесокй системы + что-то вроде IStream c содержимым для файла, + что-то, откуда можно вытащить метаинформацию, а не путь к файлу, как сейчас. И это совсем не обязательно должен быть COM. А пока этого нет, приходится использовать костыли — как NSE(костыль, далекий от идеала) или использование драйверов для обсуждаемых вещей.
Здравствуйте, carpenter, Вы писали:
... C>к стати в ХР был более менее документированный формат дополнительного потока для задания аттрибутов файла , C>что давало возможность плотно работать с самим эксплорером . C>в дурацкой висте это все переделали семерка соответственно
Да, переделали там много чего, особенно что каcается property system. Но это к лучшему, т.к. косяков там хватало.
Здравствуйте, x64, Вы писали:
ЮЖ>>>>Есть така проблема: делаем файлу "Set tags...", через неделю этот файл перемещаем в другую папку или меняем имя. Как отслуживать такие вещи? Мониторить в драйвере все файловые операции? C>>>дополнительные потоки ЮЖ>>Ага, это решение уже предлагали, я его пропустил.
x64>Да, на самом деле файловые потоки (file streams) — это хорошее универсальное решение
...
Т.е. привязка в драйвере к пути файла не используется?
разговора) — это фильтр. Это значит, что он всего лишь добавляет некую функциональность к той, что уже реализована в файловой системе. А это в свою очередь означает, что при обращении к файлам он обязан использовать те способы, которые регламентированы нижележащей ФС. В NTFS это имя, а также File ID или Object ID, в других ФС это могут быть только имя, или только ID, или... Или это может быть... да-да, тег или даже SQL-запрос ) Но это уже отдельный разговор.
Здравствуйте, x64, Вы писали:
ЮЖ>>Т.е. привязка в драйвере к пути файла не используется?
x64>Честно говоря, не очень понятно, что ты подразумеваешь под словом "привязка"? Драйвера ведь бывают разные. Драйвер (в контексте этого
Мне вот этот аспект не понятен:
x64>При чтении содержимого любой подпапки в Tags получим только те элементы, среди тегов которых есть строка, равная имени этой подпапки.
... x64>Итак, у нас есть папка "\Tags" и подпапки-теги внутри. Теперь, чтобы просмотреть все файлы, относящиеся к детям, достаточно открыть папку "\Tags\Дети".
Пусть у нас есть
d:
\Tags
\Дети
\abc
1.jpg:Дети - здесь присутствуют теги
2.jpg - здесь нет
Каким образом при открытии папки "\Tags\Дети" фильтр поймет что там нужно отобразить файл "1.jpg"? Т.е. понятно что там присутствует нужный тег. Но ведь для поиска самого файла ему придется сканировать весь диск (или отдельно указанные папки) на наличие файлов с тегами?
Под "привязкой" я подразумеваю тот факт, что драйверу нужно где-то внутри у себя хранить все пути к файлам ('d:\abc\1.jpg') которые содержат теги, и поэтому он знает где искать, а где нет. Или все подругому?
Здравствуйте, x64, Вы писали:
x64>Да, я примерно так это и вижу. Эх, там столько всего можно было бы наворотить, жаль заказа на это нету. Было б свободное время — написал бы и за так, да где ж его взять-то, это время...
Таже проблема. У меня уже достаточно начатых проектов для себя(И ни одного завершённого). Смысла начинать ещё один не вижу.
V>Некоторую теговость можно усмотреть уже в классической ФС. Например, имя файла — это однозначно один из его тегов, описывающий... да что угодно, главное, чтобы пользователю был понятен хоть немножко. Расширение — это тоже тег, худо бедно описывающий формат файла. V>А вот путь — это ни фига не набор тегов. Это адрес коробочки, в которой лежит файл. Несомненный плюс в древовидности системы каталогов — это то, что этот самый адрес можно записать в строчку по принципу "от общего к частному". Не знаю как кому, но мне удобно, что: V>1. Каждая единица хранения информации однозначно идентифицируется полным путём. И этот путь более-менее стабилен. V>2. Существует простой "естественный" способ перебора всех мест багажа. V>3. Иерархичность файловой системы естественна для базовых операций человеческого восприятия — от общего к частному и наоборот.
Я не призываю отказаться от древовидной структуры.
Хочется иметь возможность навешивать больше тэгов — имени файла и расширения не хватает.
В идеале — чтобы иерархичность файловой структуры не требовалась для поиска конкретного файла.
Здравствуйте, x64, Вы писали:
ЮЖ>>Можно с помощью драйвера получить несколько файлов с одинаковыми именами в одной папке?(я не знаю правильного ответа, но что-то мне подсказывает, что нет).
x64>Можно.
Интересно. А с этими файлами смогут работать существующие программы?
ЮЖ>>>Можно с помощью драйвера получить несколько файлов с одинаковыми именами в одной папке?(я не знаю правильного ответа, но что-то мне подсказывает, что нет). x64>>Можно. ЮЖ>Интересно. А с этими файлами смогут работать существующие программы?
Здравствуйте, x64, Вы писали:
ЮЖ>>>>Можно с помощью драйвера получить несколько файлов с одинаковыми именами в одной папке?(я не знаю правильного ответа, но что-то мне подсказывает, что нет). x64>>>Можно. ЮЖ>>Интересно. А с этими файлами смогут работать существующие программы?
x64>А почему не должны?
Не, ты не понял. На чистой системе без каких-либо файловых фильтров такой ситуации просто не будет ибо FAT и NTFS не позволяют создавать в одной папке несколько файлов с одинаковым именем. Тут без вариантов, с этим понятно, надеюсь? Далее. Поведение функции CreateFile() напрямую зависит от того, как именно файловые фильтры (если они есть в стеке) обрабатывают запросы на открытие файлов (IRP_MJ_CREATE). В случае отсутствия фильтров и в случае, если фильтр никак не обрабатывает такие запросы, для обработки запроса на открытие будет вызвана файловая система, а уж что будет дальше зависит от многих факторов — прав доступа, существования файла и т.п. Далее. Фильтр может показать приложению, что в папке есть 10 файлов и все имеют одинаковое имя. Готово ли к этому само приложение — другой вопрос, но думаю, что никаких особых проблем здесь не будет (если, конечно, приложение явно не полагается на то, что файл с таким именем может быть только один в папке), технически это возможно и обычное приложение (тот же Проводник) вполне себе увидит несколько файлов с одинаковыми именами. Но следует различать эти два момента — обработка открытия файла и обработка получения содержимого папки. Это разные запросы, и они в общем-то друг на друга не влияют. Таким образом, если фильтр самостоятельно обрабатывает получение содержимого папки, но при этом не обрабатывает открытие файла, то в поведении функции CreateFile() ничего не меняется, она будет вести себя как будто никаких фильтров нет (см. выше).
ЮЖ>>Что будет?
x64>Не, ты не понял. На чистой системе без каких-либо файловых фильтров такой ситуации просто не будет ибо FAT и NTFS не позволяют создавать в одной папке несколько файлов с одинаковым именем. Тут без вариантов, с этим понятно, надеюсь?
Это-то понятно, я папку не так назвал. Я об этом:
x64>Добавляем специальную папку в корень каждого диска. Не сами вручную добавляем, — это будет делать фильтр автоматически. Назовём эту папку "Tags". Подпапки в ней — это теги.
x64>Далее. Фильтр может показать приложению, что в папке есть 10 файлов и все имеют одинаковое имя. x64>Готово ли к этому само приложение — другой вопрос, но думаю, что никаких особых проблем здесь не будет
Вот этот момент с точки зрения "самодеятельности" ничем принципиально не отличается от ситуации с shell api, о которой я говорил.
x64>(если, конечно, приложение явно не полагается на то, что файл с таким именем может быть только один в папке),
Имхо, так делают (полагаются на это) практически все приложения. (FindFirstFile/FindNextFile + CreateFile(Folder + name).
x64>технически это возможно и обычное приложение (тот же Проводник) вполне себе увидит несколько файлов с одинаковыми именами.
Увидеть (в смысле перечислить), то он увидит. Но при любом действии над каждым из файлов, он будет делать то, что в конечном итоге сведется к CreateFile("D:\Tags\Дети\1.jpg",...), т.к. для него эта папка — по прежнему часть FS.
x64>Но следует различать эти два момента — обработка открытия файла и обработка получения содержимого папки. Это разные запросы, и они в общем-то друг на друга не влияют. Таким образом, если фильтр самостоятельно обрабатывает получение содержимого папки, но при этом не обрабатывает открытие файла
Насколько я понимаю, это не наш случай.
x64>>(если, конечно, приложение явно не полагается на то, что файл с таким именем может быть только один в папке), ЮЖ>Имхо, так делают (полагаются на это) практически все приложения. (FindFirstFile/FindNextFile + CreateFile(Folder + name).
Не совсем так. Потому что если приложению требуется вывести список файлов в папке на экран, оно выведет его так, как его вернули функции FindFirstFile() / FindNextFile(). А вот как в фильтре в обработчике открытия виртуального файла найти реальный файл в случае если виртуальных несколько и все имеют одинаковое имя — другой вопрос.
ЮЖ>Но при любом действии над каждым из файлов, он будет делать то, что в конечном итоге сведется к CreateFile("D:\Tags\Дети\1.jpg",...), т.к. для него эта папка — по прежнему часть FS.
Да, всё правильно, и единственная проблема, которую я здесь вижу, это проблема сопоставления реального файла виртуальному, описанная чуть выше.
x64>>Но следует различать эти два момента — обработка открытия файла и обработка получения содержимого папки. Это разные запросы, и они в общем-то друг на друга не влияют. Таким образом, если фильтр самостоятельно обрабатывает получение содержимого папки, но при этом не обрабатывает открытие файла ЮЖ>Насколько я понимаю, это не наш случай.
Во-первых, я об этом (о деталях реализации файлового фильтра) в контексте нашей задачи нигде ещё пока не говорил, потому что проектирование таких вещей вообще вопрос нетривиальный сам по себе, и здесь я могу говорить только навскидку. Во-вторых, это действительно не наш случай, потому что в предложенном мной варианте фильтр должен не только подменять результат запроса на чтение содержимого папки, но и перехватывать запрос на открытие файла в папке \Tags. Последнее необходимо для перенаправления запроса с виртуального файла вида \Tags\<Tag>\<File> на соответствующий ему реальный файл.
Здравствуйте, x64, Вы писали:
x64>>>(если, конечно, приложение явно не полагается на то, что файл с таким именем может быть только один в папке), ЮЖ>>Имхо, так делают (полагаются на это) практически все приложения. (FindFirstFile/FindNextFile + CreateFile(Folder + name).
x64>Не совсем так. Потому что если приложению требуется вывести список файлов в папке на экран, оно выведет его так, как его вернули функции FindFirstFile() / FindNextFile(). А вот как в фильтре в обработчике открытия виртуального файла найти реальный файл в случае если виртуальных несколько и все имеют одинаковое имя — другой вопрос.
Вот в этом я вижу очень большую проблему. Необходмо либо свое API, либо нужно использовать какие-либо хаки, либо :hz:
В NSE с этим немного проще, т.к. (хотя бы) для explorer'a Shell API является родным, а для имен там есть дополнительный уровень косвенности.
Проблема как проблема, и даже не единственная, как ты уже заметил. Но всё это решаемо. К тому же в данном случае в запасе всегда есть более кардинальное решение — спроектировать свою ФС на тегах и реализовать для неё драйвер с необходимым высокоуровневым API в виде отдельной DLL. И хотя это решение — более правильное, я не стал изначально предлагать его из-за слишком большого объёма работ.
ЮЖ>Каким образом при открытии папки "\Tags\Дети" фильтр поймет что там нужно отобразить файл "1.jpg"? Т.е. понятно что там присутствует нужный тег. Но ведь для поиска самого файла ему придется сканировать весь диск (или отдельно указанные папки) на наличие файлов с тегами?
Разумеется, сканирование всего диска на наличие тегов не подходит. Навскидку могу предложить решение с использованием индекса, который будет формироваться фильтром "на лету".
Здравствуйте, x64, Вы писали:
ЮЖ>>Вот в этом я вижу очень большую проблему.
x64>Проблема как проблема, и даже не единственная, как ты уже заметил.
Вот, вот... Были мысли приобрести готовую callable FS, но как-то грустно по совокупности стало, + времени нет, да и в драйверах я не копенгаген.
x64>Но всё это решаемо. К тому же в данном случае в запасе всегда есть более кардинальное решение — спроектировать свою ФС на тегах и реализовать для неё драйвер с необходимым высокоуровневым API в виде отдельной DLL. И хотя это решение — более правильное, я не стал изначально предлагать его из-за слишком большого объёма работ.
Звучит заманчиво, только сначала надо выяснить насколько это может быть востребовано, т.к. за интерес долго не попишешь.
Здравствуйте, x64, Вы писали:
ЮЖ>>Каким образом при открытии папки "\Tags\Дети" фильтр поймет что там нужно отобразить файл "1.jpg"? Т.е. понятно что там присутствует нужный тег. Но ведь для поиска самого файла ему придется сканировать весь диск (или отдельно указанные папки) на наличие файлов с тегами?
x64>Разумеется, сканирование всего диска на наличие тегов не подходит. Навскидку могу предложить решение с использованием индекса, который будет формироваться фильтром "на лету".
Вот это я имел ввиду под "привязкой" к пути (хотя в драйверах наверняка какие-нибудь другие имена/идентификаторы можно использовать).
Здравствуйте, alzt, Вы писали:
A>Хочется иметь возможность навешивать больше тэгов — имени файла и расширения не хватает.
Мне тоже хочется. Тоже имени и расширения не хватает. Только вот я задумался, что в эти самые теги буду писать? Некоторую метаинформацию (по сути, комменты) к содержимому файла? Не логичнее ли эти комменты писать в сам файл (как, например, в mp3), чтобы, так сказать, не было отрыва формы от содержания?
A>В идеале — чтобы иерархичность файловой структуры не требовалась для поиска конкретного файла.
Какой поиск имеется в виду? Если результатом поиска должно быть множество файлов, то теги здесь здорово помогают. А если результатом должен быть один файл (ну, или "file not found"), то теги отдыхают. Они в принципе не могут униформно лоцировать ресурс. Я например, не согласен, набрав УРЛ, получать в рожу десять тысяч открывшихся страниц. Думаю, СУБД тоже не будет рада, если по прописанному в настройках пути окажется два файла с данными
А вообще, не обращайте внимание на мой скептицизм в отношении тегов. Он обманчив. Теги — грандиозно полезная штука. Но только не для файловой системы.
Накопал немножко инфы по рассматриваемому вопросу угадайте где:
<b>Тег</b> — метка как ключевое слово, в более узком применении идентификатор, для категоризации, описания и поиска данных, задания внутренней структуры.
Примеры применения:
...
2. Информативные метки в аудио- и видеофайлах ...
...
5. Ключевое слово для категоризации в фолксономиях.
...
<b>Фолксономия</b> — народная классификация, практика совместной категоризации информации (ссылок, фото, видео клипов и т.п.) посредством произвольно выбираемых меток, называемых тегами.
Другими словами, это понятие относится к спонтанному сотрудничеству группы людей с целью организации информации, которое интересно тем, что оно полностью отличается от традиционных формальных методов фасетной классификации. <b>Фасетная классификация</b>, классификация двоеточием, классификация Ранганатана — это совокупность нескольких независимых классификаций, осуществляемых одновременно по различным основаниям, в которой:
понятия представлены в виде пересечения ряда признаков (фасетной структуры);
классификационные индексы синтезируются посредством комбинирования фасетных признаков в соответствии с фасетной формулой.
Говоря языком теории множеств, фасетная классификация — множество, элементами которого являются множества.
Говоря про то, что мы хотим навешивать на файлы теги, мы что имеем в виду? Какой принцип? Фасетную классификацию или фолксономию?
Здравствуйте, Юрий Жмеренецкий, Вы писали:
x64>>Проблема как проблема, и даже не единственная, как ты уже заметил. ЮЖ>Вот, вот... Были мысли приобрести готовую callable FS, но как-то грустно по совокупности стало, + времени нет, да и в драйверах я не копенгаген.
Эта, обращайся ко мне — у меня FUSE4Win есть
x64>>К тому же в данном случае в запасе всегда есть более кардинальное решение — спроектировать свою ФС на тегах и реализовать для неё драйвер с необходимым высокоуровневым API в виде отдельной DLL. И хотя это решение — более правильное, я не стал изначально предлагать его из-за слишком большого объёма работ. ЮЖ>Звучит заманчиво, только сначала надо выяснить насколько это может быть востребовано, т.к. за интерес долго не попишешь.
Есть мысль написать такое и продать Microsoft'у для внедрения в массы.
Здравствуйте, Voblin, Вы писали:
V>Здравствуйте, alzt, Вы писали:
A>>Хочется иметь возможность навешивать больше тэгов — имени файла и расширения не хватает.
V>Мне тоже хочется. Тоже имени и расширения не хватает. Только вот я задумался, что в эти самые теги буду писать? Некоторую метаинформацию (по сути, комменты) к содержимому файла? Не логичнее ли эти комменты писать в сам файл (как, например, в mp3), чтобы, так сказать, не было отрыва формы от содержания?
В mp3, скажем можно, в jpg тоже, а мне вот, допустим нужны "вычисляемые" теги, например количество слов в текстовом документе, или количество loc в исходнике. Куда это писать, учитывая что такие данные быстро теряю актуальность?
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, Юрий Жмеренецкий, Вы писали:
x64>>>Проблема как проблема, и даже не единственная, как ты уже заметил. ЮЖ>>Вот, вот... Были мысли приобрести готовую callable FS, но как-то грустно по совокупности стало, + времени нет, да и в драйверах я не копенгаген. C>Эта, обращайся ко мне — у меня FUSE4Win есть
Здравствуйте, Юрий Жмеренецкий, Вы писали:
ЮЖ>>>Вот, вот... Были мысли приобрести готовую callable FS, но как-то грустно по совокупности стало, + времени нет, да и в драйверах я не копенгаген. C>>Эта, обращайся ко мне — у меня FUSE4Win есть ЮЖ>Пока не актуально =)
Если надумаешь — пинай, можно очень интересные вещи сделать. Типа прозрачной интеграции с другими программами.
Здравствуйте, Cyberax, Вы писали:
... C>>>Эта, обращайся ко мне — у меня FUSE4Win есть ЮЖ>>Пока не актуально =) C>Если надумаешь — пинай, можно очень интересные вещи сделать.
Буду иметь ввиду. Насчет интересности — даже не сомневаюсь.
C>Типа прозрачной интеграции с другими программами.
Как насчет файлов с одниковыми именами в одной папке и проблемы с FindFirstFile/CreateFile (в контексте нашего разговора с x64)?
Здравствуйте, x64, Вы писали:
x64>>>К тому же в данном случае в запасе всегда есть более кардинальное решение — спроектировать свою ФС на тегах и реализовать для неё драйвер с необходимым высокоуровневым API в виде отдельной DLL. И хотя это решение — более правильное, я не стал изначально предлагать его из-за слишком большого объёма работ. ЮЖ>>Звучит заманчиво, только сначала надо выяснить насколько это может быть востребовано, т.к. за интерес долго не попишешь.
x64>Есть мысль написать такое и продать Microsoft'у для внедрения в массы.
Есть некоторый скептицизм, учитывая что произошло с WinFS. А сколько, навскидку, это человеко-лет?
Здравствуйте, Юрий Жмеренецкий, Вы писали:
x64>>Есть мысль написать такое и продать Microsoft'у для внедрения в массы. ЮЖ>Есть некоторый скептицизм, учитывая что произошло с WinFS. А сколько, навскидку, это человеко-лет?
Я бы оценил всю систему в человекогод, если не писать бездумно, а сдирать с уже существующего Nepomuk'а.
Здравствуйте, Юрий Жмеренецкий, Вы писали:
C>>Типа прозрачной интеграции с другими программами. ЮЖ>Как насчет файлов с одниковыми именами в одной папке и проблемы с FindFirstFile/CreateFile (в контексте нашего разговора с x64)?
Можно mangle'ить имена. Скажем, добавлять к ним суффикс с указанием части тэга.
Кстати, я такое уже сделал, чтобы эмулировать case sensetivity
... оставил ее для того чтоб просто что то еще на странице было.
семерка соответственно 
