Насколько я помню, если имена у файлов одинаковые, а содержание разное, то система это распознает и даст файлам префиксы с номером их инода. Она проверяет контрольную сумму содержания, если они у двух файлов совпадают, то она берет только один, а на имя столько внимания не обращает.
Это да. Даже сами разработчики предупреждают, что система стабильна, но стоит чему-то произойти в хостовой системе, целостность файла с БД может нарушиться и все насмарку.
Музыка.
Старые архивы от учебы (вдруг когда-то кому-то понадобятся старые методички или лабы).
Старые самоучители, за которые я когда-то брался и бросил, и теперь даже не знаю, что они где-то лежат.
Образы с играми, о которых я аналогично забываю, что они вообще есть, но лежат на всякий случай.
Куча всяких разных архивов… вроде и не нужны прямо сейчас, и удалить рука не подымается.
Конечно никто не заставляет тегировать все это. Только то, что важно. А потом я вдруг захочу сыграть в варгейм про вторую мировую, и вместо случайного блуждания по архивам и старым папкам «Games с С», «Games c C-2», «Games from suse» просто набью запрос "/wargame/wwii/".
Киссов послушать опять же удобно без всякого айтюнс: выбрать альбомы позже такого-то года, исключить один из альбомов и несколько песен, которые мне не нравятся, передать список в vlc или mplayer.
От позиции тега в запросе не зависит ничего, так что позиционной иерархии тегов нет.
Нет, имеется в виду репозиторий Tagsistant'а, файловый архив вкупе с внешней БД.
Их может быть несколько, чтобы не переполнять пространство тегов, к примеру репозиторий только для музыки и репозиторий только для фото. Работать с ними можно одновременно, просто точки входа будут разными. В примерах точка входа одна — ~/tagsistant/.
Почему консольные? Графические браузеры файлов нормально работают с tagfs, в том-то и половина задумки. :)
Обычные файловые операции интерпретируются Тагсистантом в свои функции, благодаря этому, как отдельно отмечают разработчики, стандартный файловый диалог отлично работает с tagfs.
Внешнее хранилище, БД? Под хранение и иерархию тегов? Так ведь тут они как раз во внешней БД и хранятся.
Видимо, да. Стоит еще учесть, что сейчас система позиционируется как предназначающаяся для Linux&BSD. NTFS таким косвенным образом изначально в пролете.
Возможно, если копировать файлы непосредственно в tagfs, вместо создания ссылок, то потом, сохранив весь репозиторий в образ, можно будет через VM его пользовать… Залить в VM ядро Linux размером мегабайт в 15 плюс библиотеки-зависимости. Но это, конечно, велосипед.
В чем-то ваша идея проще и удобней в использовании. Но наличие базовых отношений включения-исключения и неймспейсов с возможностью «искать по годам раньше указанного» (/time:/year/lt/2015/) — все-таки иногда очень к месту. Зависит от требований и ожиданий, вам вашей утилиты хватает, а мне бы вот было мало. =)
Зато у нее есть плюс, что ее можно под Windows использовать.
Этот вопрос я не вполне уловил.
Что подразумевается под точкой входа? Дело в том, что в терминологии системы это означает разные репозитории (их может быть несколько).
Поддерживать? Не знаю, у меня есть несколько архивов с самым разнообразным набором файлов, разбитых по категориям, а сами архивы разбиты по датам. Там есть все, что угодно, но особенно много картинок. Я планирую пройтись по этим архивам и пометить самые важные и интересные фотографии и картинки, а также директории, содержащие что-то интересное. Как помечу — то больше как-то и не особо собираюсь что-то поддерживать, пока не подъедет новый архив. Но уставать в поисках «того самого фото», которое я даже толком не помню в архиве за какую дату лежит — уже не придется.
А если это не фотография, а zip-архив онлайн-переписки в html-формате, то как его анализировать? Придется опять же ручками критерии создавать, не будет же анализатор за вас угадывать, что и как для вас важно.
При переносе могут измениться пути, но если пути к файлам не изменятся, если разные ФС будут поддерживать одну абстракцию иерархии. Короче говоря, допустим, вы переносите папку /home/user/Photos с ext4 на какую-нибудь ReiserFS, и в ней эта папка будет располагаться по тому же пути, то ссылки на нее и файлы в ней в tagfs не изменятся. Если я правильно понял вашу мысль. А сами теги-то в sql-формате в файле БД на месте останутся, если даже файлы пропадут.
Это достигается за счет отношений, в вашем случае include: «Германия» «содержит» названия городов, затем к фотографиям прикрепляются теги городов, но по запросу к тегу «Германия» они все будут выданы.
Плюс, возможно, можно это даже как-то оптимизировать за счет пространства имен.
Кто хочет — тот будет. У меня, например, не вызывает отторжения мысль, что придется ручками что-то пометить, если я буду знать, что потом я благодаря этим действиям очень быстро что-то найду, не перерывая десятки архивов с сотнями картинок «где же та фотография».
А автоматический анализ контента в ближайшем будущем, благодаря разработкам Google, может, и даст некоторую автоматизацию, но никогда не протегирует все именно так, как хотите вы. Если фотография содержит EXIF, то анализатор может узнать, в каком году она сделана; а если нет?
Знаете, откуда в комментариях столько зануд, рассказывающих про желтизну и бесполезность новости?
(Хотя вот я лично ничего «желтого» в новости не вижу.)
Сегодня же выступление Солнцеликого сами-знаете-где было! А тут какие-то ученые со своим Марсом. Уже целую теорию заговора успели выстроить в Кремле, а вы тут людям что-то доказываете. Говорять, нарошно людёв отвлекають своими звёздами богохульными.
Проклятые ученые, со своей наукой желтые статьи постят, вот ей-богу, глупости-то какие, право.
Ведь нельзя же! — год подряд:
То тарелками пугают — Дескать, подлые, летают;
То у вас собаки лают,
То руины — говорят!
Вы, батенька, работаете на компьютере, который работает по принципам, «железным» и программным, разработанным в своей основе в семидесятых-восьмидесятых годах прошлого века. Все последовавшие десятилетия лишь улучшали и расширяли этот функционал.
Эм… а разве PowerShell не создавался изначально как этакая копия мощной командной строки Unix? Когда у них был только убогий дос… А потом внезапно появился PowerShell, когда стало ясно, что одними оконными свистопердами ни одному админу не обойтись. Понятно, что в чем-то он круче, т.к. возможно создавался с учетом успешных примеров
Старые архивы от учебы (вдруг когда-то кому-то понадобятся старые методички или лабы).
Старые самоучители, за которые я когда-то брался и бросил, и теперь даже не знаю, что они где-то лежат.
Образы с играми, о которых я аналогично забываю, что они вообще есть, но лежат на всякий случай.
Куча всяких разных архивов… вроде и не нужны прямо сейчас, и удалить рука не подымается.
Конечно никто не заставляет тегировать все это. Только то, что важно. А потом я вдруг захочу сыграть в варгейм про вторую мировую, и вместо случайного блуждания по архивам и старым папкам «Games с С», «Games c C-2», «Games from suse» просто набью запрос "/wargame/wwii/".
Киссов послушать опять же удобно без всякого айтюнс: выбрать альбомы позже такого-то года, исключить один из альбомов и несколько песен, которые мне не нравятся, передать список в vlc или mplayer.
Была, была, но меня она не удовлетворила.
Нет, имеется в виду репозиторий Tagsistant'а, файловый архив вкупе с внешней БД.
Их может быть несколько, чтобы не переполнять пространство тегов, к примеру репозиторий только для музыки и репозиторий только для фото. Работать с ними можно одновременно, просто точки входа будут разными. В примерах точка входа одна — ~/tagsistant/.
Обычные файловые операции интерпретируются Тагсистантом в свои функции, благодаря этому, как отдельно отмечают разработчики, стандартный файловый диалог отлично работает с tagfs.
Внешнее хранилище, БД? Под хранение и иерархию тегов? Так ведь тут они как раз во внешней БД и хранятся.
Возможно, если копировать файлы непосредственно в tagfs, вместо создания ссылок, то потом, сохранив весь репозиторий в образ, можно будет через VM его пользовать… Залить в VM ядро Linux размером мегабайт в 15 плюс библиотеки-зависимости. Но это, конечно, велосипед.
В чем-то ваша идея проще и удобней в использовании. Но наличие базовых отношений включения-исключения и неймспейсов с возможностью «искать по годам раньше указанного» (/time:/year/lt/2015/) — все-таки иногда очень к месту. Зависит от требований и ожиданий, вам вашей утилиты хватает, а мне бы вот было мало. =)
Зато у нее есть плюс, что ее можно под Windows использовать.
Что подразумевается под точкой входа? Дело в том, что в терминологии системы это означает разные репозитории (их может быть несколько).
Поддерживать? Не знаю, у меня есть несколько архивов с самым разнообразным набором файлов, разбитых по категориям, а сами архивы разбиты по датам. Там есть все, что угодно, но особенно много картинок. Я планирую пройтись по этим архивам и пометить самые важные и интересные фотографии и картинки, а также директории, содержащие что-то интересное. Как помечу — то больше как-то и не особо собираюсь что-то поддерживать, пока не подъедет новый архив. Но уставать в поисках «того самого фото», которое я даже толком не помню в архиве за какую дату лежит — уже не придется.
Плюс, возможно, можно это даже как-то оптимизировать за счет пространства имен.
А автоматический анализ контента в ближайшем будущем, благодаря разработкам Google, может, и даст некоторую автоматизацию, но никогда не протегирует все именно так, как хотите вы. Если фотография содержит EXIF, то анализатор может узнать, в каком году она сделана; а если нет?
(Хотя вот я лично ничего «желтого» в новости не вижу.)
Сегодня же выступление Солнцеликого сами-знаете-где было! А тут какие-то ученые со своим Марсом. Уже целую теорию заговора успели выстроить в Кремле, а вы тут людям что-то доказываете. Говорять, нарошно людёв отвлекають своими звёздами богохульными.
Проклятые ученые, со своей наукой желтые статьи постят, вот ей-богу, глупости-то какие, право.
Ведь нельзя же! — год подряд:
То тарелками пугают — Дескать, подлые, летают;
То у вас собаки лают,
То руины — говорят!
И реверс тоже люблю. Интересная статья.
RTFM!