Comments 56
А где все эти категории хранятся? Какая-то база? Расширенные атрибуты файлов?
А насколько обосновано использование стороннего хранилища?
Есть же xattr в которых можно хранить немало информации.
И они есть во многих файловых системах в том или ином виде.
Теги туда как раз бы влезли на мой взгляд.
Это позволяет хранить метаинформацию рядом с файлами. А также переносить её в любое место без потерь.
То есть при логине пользователя или при изменении тегов просто дописывать в базу данных.
Периодически сканировать файлы и это позволит держать систему в близком к реальному состоянии.
Я рассматривал такой вариант, но натолкнулся на ограничения расширенных атрибутов, например, были проблемы с использованием русского языка. И я решил, в vitis можно игнорировать факт уже существующей поддержки файловыми системами метаинформации для файлов, я просто не нашёл как это можно применить. А периодическое сканирование состояния системы накладывает свои вопросы: если это в фоне происходит, то должен быть демон, если пользователь сам должен об этом беспокоиться, то после десятого запуска сканирования для актуализации системы ему уже будет несколько грустно этим заниматься. Сейчас у меня хранение устроено просто, и этого достаточно для осуществления задуманных функций.
Насколько я понимаю xattr хранит биты а кодировка это дело вторичное.
Индексирование, конечно, процедура затратная, но её можно делать по расписанию, ночью.
А при обычном использовании индекс будет пополняться автоматически.
Почему я за хранение индекса отдельно а метаданных отдельно.
Представим что сторонняя программа удаляет файлы, ситуация обычная.
Или индекс пропал, пользователь программы стёр директорию где конфиг лежит.
Или ещё какая-то нештатная ситуация.
Я не пытаюсь как-то умалить достижение, мне действительно интересно какие именно предпосылки были при создании.
Пример создания и чтения артрибута в UTF-8
#!/usr/bin/env python
import xattr
from pathlib import Path
TESTFILE = 'xattr-test'
ATTR = 'user.test'
ENCODING = "utf-8"
ENCODED_VALUE = bytes("Привет хабр!", ENCODING)
Path(TESTFILE).touch()
xattr.setxattr(TESTFILE, ATTR, ENCODED_VALUE)
print(xattr.getxattr(TESTFILE, ATTR).decode(ENCODING))
Согласен. Есть же мета-стор у любой современной ФС. А у ФС типа NTFS — дополнительные файловые потоки, в которые можно писать любую ахинею в любом размере.
user.xdg.tags. vitis определённо уметь писать теги туда, хотя бы как опцию, которую можно включить. Это сразу добавит интеграции (пусть и односторонней) с Dolphin, Baloo и вообще кедами.
Одна проблема — пользователи за 20-30+ лет работы с иерархией крепко на неё подсели. Сломить вот это вот «хочу фолдерА/фолдерЗед/.../документ» достаточно сложно (вопрос нужно ли) в пользу «найти по тегам».
Я полностью согласен, что фактически иерархия — это неправильная структура, т.к. фактически она одномерная. Файлы же хочется классифицировать в многомерном пространстве и имя файла является одним из измерений, не всегда даже самым важным. Единственная существенная проблема заключается в том, что вся эта концепция мультимерной ФС абсолютно несовместима с классическими иерархическими ФС. Т.е. переход из одной системы в другую всегда болезненен и при нем происходит потеря метаданных. С другой стороны мультиФС можно легко реализовать поверх иерархической ФС, заменив имена файлов guid'ами и сделав балансировку по первым символам guid, чтобы не было слишком много уровней вложенности и слишком много файлов в одном каталоге. Отдельно где-то должен лежать каталог метаданных. Но, вообще, да. Это прям reinventing google drive & sharepoint получается
Где-то был описан вариант, при котором имена файлов заменяются на их хэш-суммы, при этом очень важно, чтобы семантические атрибуты должны совершенно однозначно определяли и описывали файл. А хэш-суммы позволяют избежать дублирования данных. Это подходит для реализации настоящей файловой системы, но при этом действительно ломается возможность нормально взаимодействовать с уже существующим ПО. А так, да, файлам имена не нужны, когда есть ряд сущностей, лучше его описывающих.
На своём примере могу доказать обратное: я уже категоризировал более шести тысяч файлов, создал более тысячи категорий и псевдонимов, и это стоило того.
Как к этому вопросу подступиться людям, у которых 200 000+ файлов? И за 25 лет развития мозга (ещё со времен FIDO) накопилось пара тысяч тегов, среди которых куча всякой дряни, типа foto, photo, myphoto, old foto, photonew
Подкину мысли для размышления / реализации:
1) Как копировать сделанную выборку на флешку или в какую-то обычную директорию файловой системы? Как создать из нее архив?
2) Можно ли сделать выборку по набору тегов и представить ее как некую виртуальную директорию и затем в этой директории открыть просмотрщик изображений / медиа плеер, чтобы листать в нем по данной выборке?
3) Для медиа файлов логично иметь конвертер информации с IPTC (и EXIF) в категории файловой системы. Тогда можно удобно ставить теги в удобном специализированном софте (например XnView MP) и конвертировать их в Вашу систему.
Логичен и обратный конвертер — Ваши категории в IPTC для использования в стороннем софте.
1) Есть функция копирования файлов по запросу. Недавний реальный случай: у меня есть альбом саундтреков из короткометражки "Кунг Фьюри" и есть сама видеозапись. Мне потребовалось скопировать на флешку одному своему товарищу это видео и я сделал примерно так:
vitis copy Короткометражки i: "Кунг Фьюри" -d /mnt/flashdrive/dir
Возможно, что я неправильно проинтерпретировал вопрос.
2) Эта хорошая мысль и я давно о ней думаю: создавать что-то типа временных "комнат" по запросу с использованием виртуальной файловой системы. В этом определённо есть смысл и однажды я это сделаю.
3) Тоже разумная мысль — использовать уже имеющуюся метаинформацию, что актуально для некоторых форматов файлов. До это я просто ещё не дошёл. Идея вполне закономерна.
А это не смотрели?
https://www.tagsistant.net
Смотрел, конечно. Про tagsistant я узнал позже начала своих работ и, поизучав интерфейс, понял, что моего внимания это не стоит
Конкретнее: полагаю странным пытаться пользоваться семантической файловой системой, используя интерфейс фактически для обычной файловой системы. Воспользуюсь примерами использования tagsistant с главной страницы:
mkdir ~/myfiles/tags/startrek
mkdir ~/myfiles/tags/starwars
cp first_contact.avi ~/myfiles/store/startrek/@
cp the_return_of_the_jedi.avi ~/myfiles/store/starwars/@против
vitis assign startrek -f first_contact.avi
vitis assign starwars -f the_return_of_the_jedi.aviВыборка файлов по тэгам выглядит там так:
ls ~/myfiles/store/startrek/+/starwars/@А в vitis так:
vitis show startrek u: starwarsВ своём подходе я просто отошёл от отображения семантической ФС в виртуальную, полагая несколько некорректным делать интерфейс к семантической ФС натянутым на обычную.
Это-то понятно, но другое дело то, как оно выглядит на стороне пользователя и насколько удобно этим пользоваться. На каком-то этапе я изучал существующие решения, но всё, что я встретил, не отвечало моим требованиям, при том что у меня уже был продуман собственный подход.
Если у читателей есть интерес, то возможно. Это очень большая тема для исследования. Нужно будет рассказать про тэги MacOS, про незавершённую WinFS, про подход BeOS/HaikuOS, хэштеги и подобные понятия, активно используемые в Интернете, про Tagsistant, SemFS, иные небольшие проекты (я, кстати, видел на Github'е несколько заброшенных репозиториев на схожую тематику), про существующие встроенные возможности файловых систем, попробовать закопаться поглубже в историю вопроса. Если этим заняться, может выйти что-то добротное, но тема серьёзная по масштабу
1. это счёт
2. это счёт от брокера Икс
3. это счёт от брокера Икс за Июнь
4. это счёт от брокера Икс за Июнь из портфолио Игрек
5. это счёт от брокера Икс за Июнь из портфолио Игрек за потери по инструментам типа Зед
на плоскую структуру тегов, предоставив им возможность удобного поиска. В примере выше — это 1 и 2 и 3 и 4 и 5 с параметрами. Это безумно удобно для автоматизации процесса (это то, что нужно мне), но не столь очевидно-удобно для пользователей.
Я просто буквально сейчас работаю над подобной задачей в прожекте, где мне надо дать пользователям возможность искать-отслеживать документы на ФС из веба, но документы в ФС попадают не через веб, а вполне себе самостоятельно.
В моём случае это:
$ find . -name "*\.xl*" -o -name "*\.do*" -o -name "*\.pdf" -o -name "*\.msg" | wc -l
84187
$ find . -type d | wc -l
22978
Фактически, вот эти вот 22978 — это теги, где часть тегов, грубо говоря даты, а другие, например, имена контрагентов, то есть по сути — переменные.
rsync ~/myfiles/store/startrek/+/starwars/@/ /media/флэшка/movies_for_vacation
Не уверен, что это кому-нибудь нужно. Обычно пользователи знают где у них хранится и что. Если надо разложить один файл в разных местах, есть симлинки/хардлинки. Если надо что-то найти, есть find/locate/whereis. Для быстрого доступа есть z.
Я пользуюсь Synology Moments — оно определяет места, даты, лица и прочую информацию из фотографий и раскладывает красиво по категориям.
Google Photos умеет также.
Тоже пришел к идее категорий/тегов, но до практической реализации не дошло.
Очень полезная штука, в общем!
Смутил костыль с миграцией семантической ФС. Я в свое время рассматривал вариант хранения тегов в текстовых атрибутах файла (в NTFS). Тогда при перемещении файлов в иерархической ФС информация о тегах будет перемещаться автоматически.
Несколько раз при разборе фото пытался прикостылить категоризацию, а несколько раз пытался использовать встроенную — в "библиотеке" музыкальных плееров.
Вторая по факту работу не выполняет, и лучше этого работают собранные из иерархической ФС плейлисты.
А для первой нужно вручную потратить на обработку безумно много времени, либо использовать ПО, что см. выше.
В идеале семантические ФС должны быть проще в использовании, так как для них нужно держать в голове пару признаков вместо точных путей, на деле получается ограниченный набор признаков, при этом нужно помнить именно все проставленные, чтобы найти X, что ложится в голову хуже плоской иерархии
git-annex.branchable.com
И, в частности, https://git-annex.branchable.com/tips/metadata_driven_views/ и https://writequit.org/org/git-annex.html
Как быть потом с редактированными фотографиями?
Обычно делается директория «дата-название-события», а в случае с тэгами как быть? Так же сначало сделать директорию, а потом все файлы из нее добавить в тэговую систему?
Из обработаных фотографий решили отправить несколько особо понравившихся родственникам, как быть в этом случае?
Да, здесь есть проблемы, связанные с тем, что vitis не может быть полностью интегрированным со всеми приложениями. Как вариант, редактированная фотография сохраняется в файловое пространство, и редактированную фотографию нужно отдельно покрыть категориями. Когда это происходит массово, можно сразу куче фоток назначить одни категории. Когда будет графическая оболочка для vitis, ряд подобных проблем можно будет сгладить.
Насчёт отдельных фотографий — здесь вы мне подали идею: есть команда vitis copy <выражение> -d <каталог назначения>, её можно будет расширить с применением списка номеров, как это сделано уже в других подкомандах (например, -n 3-6,8,12-15). Ну или как вариант особо понравившиеся добавить в категорию "Избранное" и сделать что-то вроде:
vitis copy Избранное i: Фотографии_от_25.06.2019 -d <путь к флешке родственников>
Если этим родственникам требуется отправить фотки куда-нибудь в мессенджер/соц.сеть, то через окно выбора файла можно просто добраться до нужной категории в директории "Vitis" и визуально выбрать нужные фотографии.
Интернет говорит, что семантическая файловая система обычно является надстройкой над обычной (т.е. она не обязана быть настоящей ФС). Про организацию хранения я писал — да, это символические ссылки и директории стандартной ФС (ext4 или любая другая UNIX-овая с поддержкой символических ссылок). Конечно, я думал о создании настоящей файловой системы, но это не в обозримом будущем, а для всяких cd/cp/ls можно использовать и FUSE, это будет проще. На раннем этапе я создавал маленькие скрипты vts-cd, vts-cp, vts-mkcat, vts-rm и др. С развитием удобства vitis для меня они стали неактуальными. Я сознательно отошёл от виртуальной ФС, о чём я выше уже в комментариях писал. Но вообще, как доп.функция, возможно, в каком-то виде это действительно может быть полезным, это нужно будет тщательно продумать, потому что не всё так просто, возникают концептуальные проблемы.
Тэги тоже надо структурировать.
Вместо облака тэгов — напрашивается система ключ: значение.
С той же музыкой: жанры, исполнители, год выпуска...
Конечно, можно договориться, что тэги записываются как раз в таком формате, но хранятся по-прежнему россыпью.
А чтобы получить список, скажем, жанров, — придётся грепать все тэги по маске "жанр:*"?
А потом один раз очепятаться или промахнуться мимо регистра — "Жанр:....." — и привет.
Или это как-то ложится на подкатегории?
Однако не видел никого, кто бы этим пользовался :)
Всё это от лукавого! Только SFN! Только формат 8.3!
наличие директории «Vitis» в домашнем каталоге может кого-то не устраивать.
Поэтому имена таких папок обычно начинают с точки т.е. делают скрытыми
Я считал и всё ещё считаю, что пользователи должны иметь возможность явного видимого доступа к директории Vitis из своего файлового менеджера, если им потребуется удобное графическое навигирование, особенно, если что-нибудь понадобиться загрузить в браузере (выбрать фотки, скажем, в одном из комментариев эта тема поднималась).
Если переместить, то
vitis assign X/Y -n Z/Y
Это фактически переименование одной категории в другую. Подкатегория X/Y перестанет существовать. При этом Z уже должна быть создана (это поведение я скоро изменю).
Если просто скопировать одно в другое:
vitis assign Z/Y -e X/Y
Будут скопирована эта тысяча символических ссылок, да.
Т.к. ссылки мизерные, это в любом случае быстро.
При переименовании зато нет никакого копирования.
Категории вместо директорий, или Семантическая файловая система для Linux