24.06.2019 06:50
Vindex 51 13800 Источник

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


Проблема иерархических файловых систем


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


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


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


Ранее на Хабре не раз поднималась данная тема (раз, два, три, четыре и др.), здесь я описываю своё решение.


Путь к реализации


Сразу после упомянутого сна я описал в тетради командный интерфейс, обеспечивающий необходимую работу с категориями. Тогда я решил, что за неделю-две можно написать прототип, используя Python или Bash, а потом надо будет провести работу над созданием графической оболочки на Qt или GTK. Реальность, как всегда, оказалась намного суровее, и разработка затянулась.


Изначальная задумка состояла в том, чтобы прежде всего сделать программу с удобным и лаконичным интерфейсом командной строки, которая будет создавать, удалять категории, назначать категории файлам и удалять категории из файлов. Программу я назвал vitis.


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


Третьей версией я уже реально пользовался сам очень долгое время, переведя на категории несколько тысяч своих файлов. Этому в том числе сильно способствовало реализованное автодополнение bash. Но некоторые проблемы, такие как отсутствие автоматических категорий и возможность хранения одноимённых файлов, всё равно оставались, а программа уже загибалась под собственной сложностью. Так я пришёл к необходимости решать проблемы разработки сложного ПО: написать подробные требования, разработать систему функционального тестирования, изучать инструкции по пакетированию и многое другое. Сейчас я пришёл к задуманному, так что это скромное творение может быть представлено свободному сообществу. Такое специфичное управление файлами, как управление через концепцию категорий, затрагивает неожиданные вопросы и проблемы, и в решении их vitis породил вокруг себя ещё пять проектов, некоторые из них будут упомянуты в статье. Доныне vitis не приобрёл графическую оболочку, но удобство использования файловых категорий из командной строки уже перекрывает для меня любые плюсы обычного графического файлового менеджера.


Примеры использования


Начнём с простого — создадим категорию:


vitis create Музыка

Добавим в неё для примера какую-нибудь композицию:


vitis assign Музыка -f "The Ink Spots - I Don't Want To Set The World On Fire.mp3"

Посмотреть содержимое категории "Музыка" можно подкомандой "show":


vitis show Музыка

Воспроизвести её можно при помощи подкоманды "open"


vitis open Музыка

Т.к. у нас в категории "Музыка" всего один файл, то запустится только он. Для целей открытия файлов их программами по умолчанию я сделал отдельную утилиту vts-fs-open (стандартные средства типа xdg-open или mimeopen меня по ряду причин не устраивали; но, если что, в настройках вы можете указать другую утилиту для универсального открытия файлов). Эта утилита неплохо работает на разных дистрибутивах с разными рабочими средами, поэтому рекомендую вместе с vitis установить и её.


Можно и напрямую указать программу для открытия файлов:


vitis open Музыка --app qmmp


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


vitis assign Программирование R -f "Введение в R.pdf" "Статистический пакет R: теория вероятностей и матстатистика.pdf" --yes

Теперь мы хотим добавить файлу "Статистический пакет R: теория вероятностей и матстатистика.pdf" категорию "Математика". Мы знаем, что этот файл уже имеет категорию "R" и поэтому можем использовать категорийный путь из Vitis-системы:


vitis assign Математика -v "R/Статистический пакет R: теория вероятностей и матстатистика.pdf"

К счастью, автодополнение bash позволит это легко сделать.


Глянем что получилось, используя флаг --categories, чтобы увидеть список категорий у каждого файла:


vitis show R --categories


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


Добавим для разнообразия в "Математику" ещё что-нибудь:


vitis assign Математика -f "Математический анализ - 1984.pdf" Перельман_Занимательная_математика_1927.djvu

А сейчас начинается интересное. Вместо категорий можно писать выражения с операциями объединения, пересечения и вычитания, то есть использовать операции над множествами. Например, пересечение "Математики" с "R" даст в результате один файл.


vitis show R i: Математика

Вычтем из "Математики" упоминания языка "R":


vitis show Математика \\ R  #или vitis show Математика c: R

Можем бесцельно объединить музыку и язык R:


vitis show Музыка u: R

Флаг -n позволяет "выдёргивать" из результата запроса нужные файлы по номерам и/или диапазонам, например, -n 3-7, или что посложнее: -n 1,5,8-10,13. Часто бывает полезно с подкомандой open, что позволяет открывать нужные файлы из списка.



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


vitis create Математика/Статистика

vitis assign Математика/Статистика -v "R/Введение в R.pdf"

vitis show Математика --categories


Можем видеть, что этот файл теперь имеет категорию "Математика/Статистика" вместо "Математика" (лишние ссылки отслеживаются).


Обращаться по полному пути может быть неудобно, создадим "глобальный" псевдоним:


vitis assign Математика/Статистика -a Статистика

vitis show Статистика


Не только обычные файлы


Интернет-ссылки


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


vitis assign Хабр Цветоаномалия -i https://habr.com/ru/company/sfe_ru/blog/437304/ --yes

В специальном месте будет создан файл с заголовком HTML-страницы и с расширением .desktop. Это традиционый формат ярлыка в GNU/Linux. Такие ярлыки получают автоматическую категорию NetworkBookmarks.


Естественно, ярлыки создаются чтобы их использовать:


vitis open Цветоаномалия

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


Фрагменты файлов


Также полезно иметь категории для отдельных фрагментов файлов. Неплохая заявка, а? Но текущая реализация пока затрагивает только обычные текстовые файлы, аудио- и видеофайлы. Скажем, вам нужно отметить определённый кусок какого-нибудь концерта или смешной момент в фильме, тогда при использовании assign вы можете воспользоваться флагами --fragname, --start, --finish. Сохраним заставку из "Утиных историй":


vitis assign vitis assign -c Заставки -f Duck_Tales/s01s01.avi --finish 00:00:59 --fragname "Duck Tales intro"

vitis open Заставки

Реально никакого отсечения файлов не происходит, вместо этого создаётся файл-указатель на фрагмент, в котором описан тип файла, путь к файлу, начало и и конец фрагмента. Создание и открытие указателей на фрагменты делегируется утилитам, специально мною сделанным для этих целей — это mediafragmenter и fragplayer. Первая создаёт, вторая открывает. В случае аудио- и видеозаписей запуск медиафайла с определённой до определённой позиции происходит при помощи проигрывателя VLC, так что он тоже должен быть в системе. Сначала хотел сделать это на основе mplayer'а, но там почему-то очень криво было с позиционированием в нужном моменте.
В нашем примере создаётся файл "Duck Tales intro.fragpointer" (он размещается в особом месте), а затем воспроизводится фрагмент от начала файла (т.к. --start не был указан при создании) до метки в 59 секунд, после чего VLC закрывается.


Другой пример — мы решили категоризировать отдельное выступление на концерте какого-нибудь известного исполнителя:


vitis assign Лепс "Спасите наши души" -f Григорий\ Лепc\ -\ Концерт\ Парус\ -\ песни\ Владимира\ Высоцкого.mp4 --fragname "Спасите наши души" --start 00:32:18 --finish 00:36:51

vitis open "Спасите наши души"

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


Как это всё работает + дополнительные возможности


Хранение категорий


В самом начале продумывания организации семантической файловой системы мне пришло на ум три способа: через хранение символических ссылок, посредством базы данных, через описание в XML. Победил первый способ, т.к. он, с одной стороны, прост в реализации, а с другой — у пользователя есть возможность смотреть на категории прямо из файловой системы (и это удобно и важно). В начале использования vitis в домашней директории пользователя создаётся директория "Vitis" и конфигурационный файл ".config/vitis/vitis.conf". В ~/Vitis создаются директории, соответствующие категориям, а в этих директориях-категориях создаются символические ссылки на оригинальные файлы. Псевдонимы категорий — это тоже просто ссылки на них. Конечно, наличие директории "Vitis" в домашнем каталоге может кого-то не устраивать. Можем переключиться на любое другое место:


vitis service set path /mnt/MyFavoriteDisk/Vitis/

В определённый момент становится понятно, что разрозненные по разным местам файлы малоосмысленно категоризировать, посколько их расположение может меняться. Поэтому я для начала создал себе директорию, куда тупо сбрасывал всё и давал этому всему категории. Затем решил, что неплохо бы этот момент оформить на программном уровне. Так появилось понятие "файлового пространства". В начале использования vitis сразу не помешало бы настроить такое место (туда будут складироваться все нужные нам файлы) и включить автосохранение:


vitis service add filespace /mnt/MyFavoriteDisk/Filespace/

vitis service set autosave yes

Без автосохранения при использовании подкоманды "assign" будет требоваться флаг --save, если будет возникать желание сохранить добавляемый файл в файловое пространство.


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


Миграция семантической файловой системы


Так или иначе, директория Vitis и файловые пространства теоретически иногда могут переезжать с места на место. Для приведения к работоспособности я создал отдельную утилиту link-editor, которая может массово редактировать ссылки, заменяя части пути на другие:


cp -r /mnt/MyFavoriteDisk/Vitis/ ~/Vitis
link-editor -d ~/Vitis/ -f /mnt/MyFavoriteDisk/Vitis/ -r ~/Vitis/ -R
cp -r /mnt/MyFavoriteDisk/Filespace/ ~/MyFiles
link-editor -d ~/Vitis/ -f /mnt/FlashDrive-256/Filespace/ -r ~/MyFiles -R

В первом случае после того, как мы переехали из /mnt/MyFavoriteDisk/Vitis/ в домашнюю директорию, редактируются символические ссылки, связанные с псевдонимами. Во втором случае после изменения расположения файлового пространства изменяются все ссылки в Vitis на новые сообразно запросу замены части их пути.


Автоматические категории


Если запустить команду vitis service get autocategorization, то можно увидеть, что по умолчанию настроено назначение автоматических категорий по формату (Format и Type) и расширению файлов (Extension).


Это полезно, когда например вам что-то нужно найти среди PDF-ок или глянуть, что у вас хранится из MOBI и FB2, можно просто выполнить запрос


vitis show Format/MOBI u: Format/FB2

Так уж получилось, что стандартные средства GNU/Linux типа file или mimetype меня не устроили именно по той причине, что они не всегда верно определяют формат, пришлось делать свою реализацию по сигнатурам файлов и расширениям. Вообще, тема для определения форматов файлов — интересная тема для исследований и заслуживает отдельной статьи. Пока могу сказать, что, возможно, не для всех форматов в мире я предусмотрел правдивое распознавание, но в целом уже сейчас оно работает неплохо. Правда, у EPUB сейчас определяется формат как ZIP (в общем-то оправданно, но на практике это не стоит считать нормальным поведением). До некоторых пор считайте эту возможность экспериментальной, о багах сообщайте. В странных ситуациях всегда можно использовать категории по расширению файлов, например, Extension/epub.


Если включены автокатегории по формату, также включены автокатегории, объединяющие некоторые форматы по типу: "Archives", "Pictures", "Video", "Audio" и "Documents". Для этих подкатегорий тоже будут сделаны локализованные названия.


О чём не сказано


vitis получился очень многогранным инструментом, и сложно всё охватить сразу. Кратко упомяну о том, что ещё можно делать:


  • категории можно удалять и убирать их от файлов;
  • результаты запросов по выражениям можно копировать в указанную директорию;
  • файлы можно запускать как программы;
  • у команды show множество опций, например, сортировка по имени/дате изменения или обращения/размеру/расширению, показ свойств файлов и путей к оригиналам, включение отображения скрытых файлов и др.;
  • при сохранении ссылок на Интернет-источники можно также сохранять локальные копии HTML-страниц.

Все подробности можно найти в пользовательской справке.


Перспективы


Часто скептики говорят о том, что "никто эти тэги сам расставлять не станет". На своём примере могу доказать обратное: я уже категоризировал более шести тысяч файлов, создал более тысячи категорий и псевдонимов, и это стоило того. Когда одной командой vitis open План открываешь список своих дел или когда одной командой vitis open LaTeX открываешь книгу Столярова про систему вёрстки LaTeX, то уже морально сложно пользоваться файловой системой "по старинке".


На этой почве возникает ряд идей. К примеру, можно сделать автоматическое радио, которое включает тематическую музыку сообразно текущей погоде, празднику, дню недели, времени суток или года. Ещё близко к теме — музыкальный проигрыватель, который знает про категории и может проигрывать музыку по выражению с операциями над категориями как над множествами. Полезно сделать демон, который будет следить за каталогом "Загрузки" и будет предлагать категоризировать новые файлы. Ну и, конечно, следует бы сделать нормальный графический семантический файловый менеджер. Когда-то я даже делал для предприятия веб-сервис для коллективного использования файлов, но он был не приоритете и стал неактуальным, хотя и достиг высокого уровня работоспобности. (В связи с большими изменениям в самом vitis, он уже непригоден к использованию.)


здесь маленькая демонстрация


Заключение


Vitis — не первая попытка радикально изменить стиль работы со данными, но я посчитал важным реализовать свои идеи и выложить реализацию в открытый доступ под лицензией GNU GPL. Для удобства сделан deb-пакет для x86-64, он должен работать на всех современных Debian-дистрибутивах. На ARM оказались небольшие сложности (при этом все остальные программы, связанные с vitis, работают нормально), но в дальнейшем и под эту платформу (armhf) будет собран работающий пакет. Созданием RPM-пакетов пока перестал заниматься в связи с проблемами на Fedora 30 и проблематичностью распыляться на множество RPM-дистрибутивов, но позже всё равно хоть для пару из них будут делаться пакеты. А пока можно пользоваться make && make install или checkinstall.


Всем спасибо за внимание! Надеюсь, данная статья и данный проект смогут оказаться полезными.


Ссылка на репозиторий проекта

Комментарии (51)


  1. NeoCode
    24.06.2019 10:01
    #20316674

    А где все эти категории хранятся? Какая-то база? Расширенные атрибуты файлов?


    1. Vindex Автор
      24.06.2019 11:30
      #20317054

      В статье я уже упомянул, что категории являются директориями с символическими ссылками на оригинальные файлы. Были мысли сделать это на основе БД, но с точки зрения удобства и наглядности, это не самый хороший вариант. Расширенные атрибуты файлов — прикольно, но при запросе определённой категории пришлось бы сканировать сразу все категоризированные файлы в попытке найти нужные с запрошенным атрибутом.


      1. nad_oby
        25.06.2019 09:57
        #20320772

        А насколько обосновано использование стороннего хранилища?
        Есть же xattr в которых можно хранить немало информации.
        И они есть во многих файловых системах в том или ином виде.
        Теги туда как раз бы влезли на мой взгляд.
        Это позволяет хранить метаинформацию рядом с файлами. А также переносить её в любое место без потерь.
        То есть при логине пользователя или при изменении тегов просто дописывать в базу данных.
        Периодически сканировать файлы и это позволит держать систему в близком к реальному состоянии.


        1. Vindex Автор
          25.06.2019 11:05
          #20321128

          Я рассматривал такой вариант, но натолкнулся на ограничения расширенных атрибутов, например, были проблемы с использованием русского языка. И я решил, в vitis можно игнорировать факт уже существующей поддержки файловыми системами метаинформации для файлов, я просто не нашёл как это можно применить. А периодическое сканирование состояния системы накладывает свои вопросы: если это в фоне происходит, то должен быть демон, если пользователь сам должен об этом беспокоиться, то после десятого запуска сканирования для актуализации системы ему уже будет несколько грустно этим заниматься. Сейчас у меня хранение устроено просто, и этого достаточно для осуществления задуманных функций.


          1. nad_oby
            25.06.2019 14:56
            #20322616

            А какие проблемы с русским?
            Насколько я понимаю 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))


        1. gecube
          25.06.2019 11:20
          #20321238

          Согласен. Есть же мета-стор у любой современной ФС. А у ФС типа NTFS — дополнительные файловые потоки, в которые можно писать любую ахинею в любом размере.


          1. nad_oby
            25.06.2019 15:00
            #20322640

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


        1. Self_Perfection
          25.06.2019 13:03
          #20321878

          KDE для хранения тегов уже очень давно использует расширенный атрибут user.xdg.tags. vitis определённо уметь писать теги туда, хотя бы как опцию, которую можно включить. Это сразу добавит интеграции (пусть и односторонней) с Dolphin, Baloo и вообще кедами.


          1. index0h
            28.06.2019 02:48
            #20334958

            Подскажите, есть ли что-то подобное для Nautilus?


  1. rezdm
    24.06.2019 11:20
    #20317004

    Привет sharepoint, тот же гуглдрайв api и всё такое.
    Одна проблема — пользователи за 20-30+ лет работы с иерархией крепко на неё подсели. Сломить вот это вот «хочу фолдерА/фолдерЗед/.../документ» достаточно сложно (вопрос нужно ли) в пользу «найти по тегам».


    1. gecube
      24.06.2019 23:36
      #20319950

      Я полностью согласен, что фактически иерархия — это неправильная структура, т.к. фактически она одномерная. Файлы же хочется классифицировать в многомерном пространстве и имя файла является одним из измерений, не всегда даже самым важным. Единственная существенная проблема заключается в том, что вся эта концепция мультимерной ФС абсолютно несовместима с классическими иерархическими ФС. Т.е. переход из одной системы в другую всегда болезненен и при нем происходит потеря метаданных. С другой стороны мультиФС можно легко реализовать поверх иерархической ФС, заменив имена файлов guid'ами и сделав балансировку по первым символам guid, чтобы не было слишком много уровней вложенности и слишком много файлов в одном каталоге. Отдельно где-то должен лежать каталог метаданных. Но, вообще, да. Это прям reinventing google drive & sharepoint получается


      1. Vindex Автор
        25.06.2019 00:55
        #20320070

        Где-то был описан вариант, при котором имена файлов заменяются на их хэш-суммы, при этом очень важно, чтобы семантические атрибуты должны совершенно однозначно определяли и описывали файл. А хэш-суммы позволяют избежать дублирования данных. Это подходит для реализации настоящей файловой системы, но при этом действительно ломается возможность нормально взаимодействовать с уже существующим ПО. А так, да, файлам имена не нужны, когда есть ряд сущностей, лучше его описывающих.


        1. gecube
          25.06.2019 01:11
          #20320092

          А хэш-суммы позволяют избежать дублирования данных.

          Опасная история, т.к. возможны хэш-коллизии.


  1. Gaernebjorn
    24.06.2019 13:44
    #20317874

    На своём примере могу доказать обратное: я уже категоризировал более шести тысяч файлов, создал более тысячи категорий и псевдонимов, и это стоило того.
    Как к этому вопросу подступиться людям, у которых 200 000+ файлов? И за 25 лет развития мозга (ещё со времен FIDO) накопилось пара тысяч тегов, среди которых куча всякой дряни, типа foto, photo, myphoto, old foto, photonew


    1. Vindex Автор
      24.06.2019 14:11
      #20318014

      Как раз чтобы не плодить «дрянь», можно делать псевдонимы. При добавлении новых категорий перебором на автодополнении можно себе напомнить названия существующих категорий. Да, здесь тоже не помешает следить за чистотой в структуре категорий: «photonew», например, никак не может характеризовать файлы в долгосрочной перспективе (в данном случае могли бы подойти категории, связанные с тематикой фоток, временем, названием фотоаппарата и т.д.). Что касается вопроса о 200 000+, то для начала можно всё автоматически категоризировать по формату/типу/расширениям (в vitis это есть), что уже будет неплохо. Потом по мере использования можно иногда добавлять нужные категории. Да, временные затраты при появлении новых файлов могут превышать простое копирование/скачивание в нужную директорию. Зато скорость доступа становится гораздо выше, когда не нужно «ручками» добираться до нужного файла в нужной директории. Конечно, это только мой личный опыт и моё субъективное мнение. Посчитав, что оно того стоит, я оформлял это дело изначально как свободный проект в надежде, что он кому-нибудь может быть полезен.


  1. mactep3230
    24.06.2019 17:58
    #20319104

    Вот был бы сервис с api который по хешу файла возвращал тэги. Может тогда многие смогли бы пользоваться подобной системой. Или есть такой? Понятно, что с личными файлами он не поможет.


    1. masai
      24.06.2019 19:44
      #20319446

      Можно угадывать тег по содержимому. Лучше, чем ничего.


  1. DaneSoul
    24.06.2019 21:16
    #20319666

    В тегированной файловой системе самое интересное — это ее взаимодействие со сторонним софтом.
    Подкину мысли для размышления / реализации:
    1) Как копировать сделанную выборку на флешку или в какую-то обычную директорию файловой системы? Как создать из нее архив?
    2) Можно ли сделать выборку по набору тегов и представить ее как некую виртуальную директорию и затем в этой директории открыть просмотрщик изображений / медиа плеер, чтобы листать в нем по данной выборке?
    3) Для медиа файлов логично иметь конвертер информации с IPTC (и EXIF) в категории файловой системы. Тогда можно удобно ставить теги в удобном специализированном софте (например XnView MP) и конвертировать их в Вашу систему.
    Логичен и обратный конвертер — Ваши категории в IPTC для использования в стороннем софте.


    1. Vindex Автор
      24.06.2019 22:12
      #20319778

      1) Есть функция копирования файлов по запросу. Недавний реальный случай: у меня есть альбом саундтреков из короткометражки "Кунг Фьюри" и есть сама видеозапись. Мне потребовалось скопировать на флешку одному своему товарищу это видео и я сделал примерно так:
      vitis copy Короткометражки i: "Кунг Фьюри" -d /mnt/flashdrive/dir
      Возможно, что я неправильно проинтерпретировал вопрос.
      2) Эта хорошая мысль и я давно о ней думаю: создавать что-то типа временных "комнат" по запросу с использованием виртуальной файловой системы. В этом определённо есть смысл и однажды я это сделаю.
      3) Тоже разумная мысль — использовать уже имеющуюся метаинформацию, что актуально для некоторых форматов файлов. До это я просто ещё не дошёл. Идея вполне закономерна.


  1. zim32
    24.06.2019 21:34
    #20319698

    А это не смотрели?
    https://www.tagsistant.net


    1. Vindex Автор
      24.06.2019 22:17
      #20319798

      Смотрел, конечно. Про tagsistant я узнал позже начала своих работ и, поизучав интерфейс, понял, что моего внимания это не стоит


      1. zim32
        24.06.2019 23:01
        #20319882
        +1

        Я извиняюст а что конеректо там не устроило? Вроде тегирует, ищет, запускает. Я просто спрашиваю потому что не пользовался не тем не тем интересно сравнить, возможно буду использовать что-то


        1. Vindex Автор
          24.06.2019 23:25
          #20319932

          Конкретнее: полагаю странным пытаться пользоваться семантической файловой системой, используя интерфейс фактически для обычной файловой системы. Воспользуюсь примерами использования 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

          В своём подходе я просто отошёл от отображения семантической ФС в виртуальную, полагая несколько некорректным делать интерфейс к семантической ФС натянутым на обычную.


          1. zim32
            24.06.2019 23:33
            #20319946

            Хм… Возможно. Хотя если так подумать Ваша программа тоже есть ни что иное как интерфейс в семантической ФС поверх обычной. Но спасибо за Ваше мнение.


            1. Vindex Автор
              24.06.2019 23:55
              #20319986

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


              1. DaneSoul
                25.06.2019 00:13
                #20320008

                А не хотите сделать обзорную статью по существующим решениям и их ньюансам и недостаткам? Думаю многим будет интересно поближе познакомится с этой темой.


                1. Vindex Автор
                  25.06.2019 00:40
                  #20320052

                  Если у читателей есть интерес, то возможно. Это очень большая тема для исследования. Нужно будет рассказать про тэги MacOS, про незавершённую WinFS, про подход BeOS/HaikuOS, хэштеги и подобные понятия, активно используемые в Интернете, про Tagsistant, SemFS, иные небольшие проекты (я, кстати, видел на Github'е несколько заброшенных репозиториев на схожую тематику), про существующие встроенные возможности файловых систем, попробовать закопаться поглубже в историю вопроса. Если этим заняться, может выйти что-то добротное, но тема серьёзная по масштабу


                  1. rezdm
                    25.06.2019 15:32
                    #20322782

                    Я повторюсь — Вы написали «бек-енд» МС шэйрпоинт, гугл-драйв, что-то там оффис 365 с облачным диском, т.п. Вопрос не в самом бекенде, а в том, как перевести пользователей с

                    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 — это теги, где часть тегов, грубо говоря даты, а другие, например, имена контрагентов, то есть по сути — переменные.


          1. Self_Perfection
            25.06.2019 12:54
            #20321818
            +2

            Интерфейс к ФС в виде стандартных файловых путей даёт возможность использовать сонм уже существующих утилит. Например:

            rsync ~/myfiles/store/startrek/+/starwars/@/ /media/флэшка/movies_for_vacation


          1. vlivyur
            25.06.2019 14:38
            #20322508

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


  1. Anonym
    25.06.2019 02:13
    #20320166

    Не уверен, что это кому-нибудь нужно. Обычно пользователи знают где у них хранится и что. Если надо разложить один файл в разных местах, есть симлинки/хардлинки. Если надо что-то найти, есть find/locate/whereis. Для быстрого доступа есть z.


    1. DaneSoul
      25.06.2019 13:30
      #20322038

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


      1. Anonym
        25.06.2019 15:11
        #20322688

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


    1. vlivyur
      25.06.2019 14:49
      #20322574

      Любая каталогизация начинает страдать когда можно несколькими способами разложить. И мне, как пользователю, проще было б назначить теги файлу, чем лазить по каталогам и распихивать файл/линки в разные места. А для фотографий это вообще единственный способ (дата, место, объект, событие, дополнительные произвольные признаки — равнозначные категории, не связанные иерархией). Всё будет зависеть только от удобства поиска по тегам (фотографии с дней рождений тёти Зины после её очередного восемнадцатилетия против где я был в июне 2019 — на дне рождения тёти Зины в том числе).


      1. Anonym
        25.06.2019 15:11
        #20322684

        А будете ли вы отмечать каждую новую фотографию тэгом? Для этого есть специальный софт, который справится с этой задачей чуть лучше.
        Я пользуюсь Synology Moments — оно определяет места, даты, лица и прочую информацию из фотографий и раскладывает красиво по категориям.
        Google Photos умеет также.


        1. vlivyur
          25.06.2019 15:21
          #20322734

          Если вам надо, то вы будете готовы. Где-то каждую фотографию, где-то целиком альбомами. Места оно определяет по GPS, но не все фотографии обладают этим тегом, а где-то места именуются так, что лучше не надо. С лицами проще (или сложнее, но оно уже есть), но не работает на собаках и плохо на растущих младенцах. Остальное немного есть в EXIF. Но как только хочется чего-то, чего нет в EXIF — приходиться забывать об этом, либо мучиться с линками.


  1. DmitryITWorksMakarov
    25.06.2019 09:28
    #20320652

    Каждый раз когда пытался навести порядок в своих фото, музыке, электронных книгах становилось понятно, что иерархическая файловая система не годится для этого. Музыку хочется разместить и по музыканту, и по жанрам, и по году выхода. Бывает что над композицией работает несколько авторов или композиция кроссжанровая (очень часто). Также и с книгами. С фото своя классификация: и по месту, и по дате, и по людям на них.

    Тоже пришел к идее категорий/тегов, но до практической реализации не дошло.

    Очень полезная штука, в общем!

    Смутил костыль с миграцией семантической ФС. Я в свое время рассматривал вариант хранения тегов в текстовых атрибутах файла (в NTFS). Тогда при перемещении файлов в иерархической ФС информация о тегах будет перемещаться автоматически.


    1. Vindex Автор
      25.06.2019 10:44
      #20320988

      Согласен, что это выглядит как костыль, однажды добавлю команду vitis migrate .... Так или иначе даже в аварийном случае ситуация перемещения всё равно легко исправляется.


  1. DerRotBaron
    25.06.2019 11:10
    #20321162

    Несколько раз при разборе фото пытался прикостылить категоризацию, а несколько раз пытался использовать встроенную — в "библиотеке" музыкальных плееров.
    Вторая по факту работу не выполняет, и лучше этого работают собранные из иерархической ФС плейлисты.
    А для первой нужно вручную потратить на обработку безумно много времени, либо использовать ПО, что см. выше.


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


  1. leon_nikitin
    25.06.2019 11:45
    #20321386

    Смотрели в сторону git annex?
    git-annex.branchable.com
    И, в частности, https://git-annex.branchable.com/tips/metadata_driven_views/ и https://writequit.org/org/git-annex.html


    1. Vindex Автор
      25.06.2019 13:27
      #20322010

      Нет, этого я не встречал. Изучу на досуге


  1. vit41ik
    25.06.2019 13:31
    #20322046

    Как быть в случае например с фотографиями, отсняли какое-нибудь событие(свадьбу). Сырых фотографий скажем 1000 шт. Без проблем можно их добавить в тэговую систему, добавить теги с название события, даты и прочее, а потом это все запустить на редактирование.
    Как быть потом с редактированными фотографиями?
    Обычно делается директория «дата-название-события», а в случае с тэгами как быть? Так же сначало сделать директорию, а потом все файлы из нее добавить в тэговую систему?
    Из обработаных фотографий решили отправить несколько особо понравившихся родственникам, как быть в этом случае?


    1. Vindex Автор
      25.06.2019 13:43
      #20322116

      Да, здесь есть проблемы, связанные с тем, что vitis не может быть полностью интегрированным со всеми приложениями. Как вариант, редактированная фотография сохраняется в файловое пространство, и редактированную фотографию нужно отдельно покрыть категориями. Когда это происходит массово, можно сразу куче фоток назначить одни категории. Когда будет графическая оболочка для vitis, ряд подобных проблем можно будет сгладить.
      Насчёт отдельных фотографий — здесь вы мне подали идею: есть команда vitis copy <выражение> -d <каталог назначения>, её можно будет расширить с применением списка номеров, как это сделано уже в других подкомандах (например, -n 3-6,8,12-15). Ну или как вариант особо понравившиеся добавить в категорию "Избранное" и сделать что-то вроде:
      vitis copy Избранное i: Фотографии_от_25.06.2019 -d <путь к флешке родственников>
      Если этим родственникам требуется отправить фотки куда-нибудь в мессенджер/соц.сеть, то через окно выбора файла можно просто добраться до нужной категории в директории "Vitis" и визуально выбрать нужные фотографии.


  1. sickfar
    25.06.2019 14:03
    #20322282

    Вы пишете в заголовке статьи «Семантическая файловая система», это действительно так? Или же вы оперируете директориями стандартной ФС (ext4?), создавая дополнительные файлы и оперируя ссылками? Если последнее, то не рассматривали упаковать в действительно файловую систему, манипулировать разметкой диска? Тогда и поддержка стандартных команд sh будет, таких как cd/cp/ls и прочее. Идея отличная, отложу себе в закладки. Однажды доберусь в своей ОС до файловой системы и попытаюсь в категории :)


    1. Vindex Автор
      25.06.2019 14:20
      #20322388

      Интернет говорит, что семантическая файловая система обычно является надстройкой над обычной (т.е. она не обязана быть настоящей ФС). Про организацию хранения я писал — да, это символические ссылки и директории стандартной ФС (ext4 или любая другая UNIX-овая с поддержкой символических ссылок). Конечно, я думал о создании настоящей файловой системы, но это не в обозримом будущем, а для всяких cd/cp/ls можно использовать и FUSE, это будет проще. На раннем этапе я создавал маленькие скрипты vts-cd, vts-cp, vts-mkcat, vts-rm и др. С развитием удобства vitis для меня они стали неактуальными. Я сознательно отошёл от виртуальной ФС, о чём я выше уже в комментариях писал. Но вообще, как доп.функция, возможно, в каком-то виде это действительно может быть полезным, это нужно будет тщательно продумать, потому что не всё так просто, возникают концептуальные проблемы.


      1. sickfar
        25.06.2019 14:30
        #20322452

        Извините, был не очень внимателен значит. Удачи вашему проекту!


  1. nickolaym
    25.06.2019 21:16
    #20324146

    Тэги тоже надо структурировать.
    Вместо облака тэгов — напрашивается система ключ: значение.
    С той же музыкой: жанры, исполнители, год выпуска...


    Конечно, можно договориться, что тэги записываются как раз в таком формате, но хранятся по-прежнему россыпью.
    А чтобы получить список, скажем, жанров, — придётся грепать все тэги по маске "жанр:*"?
    А потом один раз очепятаться или промахнуться мимо регистра — "Жанр:....." — и привет.


    Или это как-то ложится на подкатегории?


    1. Self_Perfection
      26.06.2019 01:11
      #20324716

      А почивший tagsistant это умел! Пример из его документации:

      ls ~/myfiles/store/=maiden_videos/time:/year/lt/1985/@/


    1. vlivyur
      26.06.2019 11:56
      #20326154

      Если нормализовать дальше, то между тегами ещё и иерархия есть (жанр есть в кино, музыке, книгах и пр.). А актёры иногда режиссёрами становятся.


  1. Radic
    26.06.2019 19:08
    #20328734

    В макоси поддержка тэгов в файлах есть лет пять, в фото/музыке — совсем давно. Глубокая интеграция с ОС/ПО.
    Однако не видел никого, кто бы этим пользовался :)


  1. denisgrim
    27.06.2019 01:08
    #20329852

    Всё это от лукавого! Только SFN! Только формат 8.3!