Пользователь
30 мая 2012 в 12:33

Разработка → Можно ли прибраться на компе раз и навсегда?

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

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

PersonalBrain ( www.thebrain.com )

Довольно хорошая утилита для организации файлов, папок и url-ссылок. Минусы: платная, довольно медленная (Java-based), нельзя пометить тегом сразу большую группу объектов. Плюсы: есть возможность переключать виды (облако, дерево, таблица).

tag2find ( www.tag2find.com )

Утилита для пометки файлов тегами и поиска по ним. Минусы: работает только под Windows, трудно пометить тегом сотни файлов.

dhtfs ( code.google.com/p/dhtfs )

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

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

Чего бы хотелось

1. При попадании любого файла на комп (в том числе при установке программ, распаковке архивов и пр.) он автоматически помечается следующими тегами:
— откуда скачан (урл, локальный путь с указанием имени компьютера, откуда он был скачан, либо имя данного компьютера, если он был создан на нем с нуля, плюс ссылка на оригинальный файл и его версию, если это копия или версия другого файла)
— дата создания (когда скачан, timestamp)
— дата обновления=дата создания
— полное имя файла (в кодировке UTF-8)
— MIME-тип файла
— человеческое название MIME-типа (музыка, программа, видео)
— размер файла
Данная метаинформация обладает версионностью.
2. Пользователь может в любой момент добавить к файлу любое кол-во других тегов, изменить и удалить их. Удалить и изменить автоматические теги вручную нельзя. При добавлении-изменении-удалении тегов существуют два варианта сохранения, см.ниже.
3. При создании, изменении и сохранении любого файла (и метаинформации) существуют два варианта сохранения:
3.1 Сохранение мелкой правки файла: содержимое, размер файла и дата обновления перезаписываются. Сохранение мелкой правки метаинформации: добавление-изменение-удаление тегов без сохранения истории.
3.2 Полное сохранение (коммит) файла: создается новая версия файла и метаинформации. Полное сохранение (коммит) метаинформации: создается ее новая версия.
Выбор варианта сохранения — два хоткея, например: F2 — Save, Shift+F2 — Commit. При нажатии любого из них всплывает строка ввода, в которую можно ввести теги через запятую (в первом случае — это просто теги (которые могут, конечно, состоять из нескольких слов), в случае commit это будет commit-сообщение). Эти же операции можно осуществлять с группой файлов.
4. При отсутствии критерия поиска вид по умолчанию — дерево, в котором файлы упорядочены по следующему списку критериев-тегов: человеческое название MIME-типа, дата обновления, полное имя файла. Данный список можно редактировать: менять порядок тегов, добавлять и удалять теги из списка автоматических. Можно создавать новые списки тегов и сохранять их как виды. Деревом же можно пользоваться так же, как обычной файловой системой — заходить и выходить из «папок»-тегов, сортировать файлы. Например, создание папки и перенос туда файлов будет означать создание пользовательского тега и присвоение его файлам.
5. Поиск по умолчанию ведется только среди последних версий метаинформации. Интерфейс поиска состоит из двух панелей: на одной находится набор контролов для фильтрации поиска по стандартным атрибутам (дата создания, обновления, человеческое название MIME-типа, размер от, размер до), на другой — строка ввода (ищет и по стандартным, и по пользовательским атрибутам, также ищет по частям тегов, есть автокомплит).
6. Результаты поиска показываются в виде таблицы файлов с колонками: версия метаданных-версия файла-имя-размер-человеческое название MIME-типа-дата создания-дата обновления-откуда скачан-пользовательские теги/commit-сообщение. Порядок колонок можно менять, нажатием на заголовок колонки можно сортировать вывод по данной колонке. Внизу выводится общее количество файлов и время, затраченное на поиск. Поисковые запросы можно сохранять и использовать позже.
7. Для каждого файла из контекстного меню доступны команды «посмотреть историю метаинформации», «посмотреть историю файла», «получить версию файла» (при этом на полученный файл распространяются все критерии выше, что позволяет построить граф копий и версий одного файла)
8. При покидании компа (или удалении файла) метаинформация и содержимое файла удаляются вместе со всей историей.

Этапы достижения идеального

Виртуальная файловая система с реализацией файлового менеджера под нее и git-like версионностью — дело непростое. Для начала можно просто попробовать сделать надстройку-демон, реализующую описанные функции и работающую поверх существующих файлосистем (NTFS, ext3/4). Нужно также поставить git и положить в него весь жесткий диск. Далее демон отслеживает
— появление всех новых файлов, помечая их автотегами и добавляя в git
— перенос, модификацию и удаление файлов, обновляя информацию в базе-хранилище и в git
— отвечает на запросы к базе, выдавая результаты
Плюс интерфейс поиска/файловый менеджер, хотя бы в виде плагинов к total commander/FAR/Nautilus/mc (да простят меня поклонники макоси за то, что я не пользуюсь их системой).

Да, я забыл упомянуть Google Desktop [почивший 14 сентября 2011, googledesktop.blogspot.com/2011/09/google-desktop-update.html], а также Copernic Desktop Search и прочие en.wikipedia.org/wiki/Desktop_search) Почему? Во-первых, они ищут еще и в файлах (контент внутри файлов), что не требовалось. Во-вторых, версионность в этих движках отсутствует. Справедливости ради все же замечу, что в них реализована часть из описанного мной функционала, поэтому рассмотрение данных движков имеет смысл — возможно, я сделаю это в последующих статьях.

P.S. Кстати, есть предположение (того же Гугла), что вскоре все будут мигрировать в веб и в облака, поэтому десктоп-поисковики маст дай. Насчет этого я не согласен: человеку нужно иметь private place и контроль над информацией без доступа посторонних, как бы Гуглу ни хотелось знать все обо всех. Да и в торренты вряд ли кто-то будет когда-нибудь выкладывать абсолютно все. Так что у десктоп-поиска с версионностью есть будущее.
Andrew Answer @andrew_answer
карма
19,0
рейтинг 0,0
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Реклама

Самое читаемое Разработка

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

  • +29
    У меня ни одно подобное средство не прижилось. Оказалось, что свалка удобнее.
    • +1
      Как ищете? По имени файла? Все переименовываете? А предположим, в прошлом году написали программку, а сейчас хотите ее в портфолио выложить? А если вы решили видеоклип из фильмов сделать и озвучить самостоятельно? Не бесит искать?
      • +9
        иерархия же… Работа/2011/Dev/MuSuperProgram
      • +1
        имя файла + контент — стандартный поиск винды, который нужен редко — у меня все структурировано. только музыку ищу по тегам из медиаплеера.
    • +1
      Это если вы работаете один и вам не часто приходится обращается к работам 3-5 летней давности.
  • +43
    Раньше я жил один, и все мои вещи как попало валялись на своих местах. Теперь у меня появилась девушка, а все мои вещи аккуратно и красиво лежат неизвестно где. (с) Не помню откуда
    • 0
      Эта цитата ставит крест сразу на всей системе тегов, теги чаще всего индивидуальны, то есть теги которые придут в голову ко мне, и те что будут важны для вас будут отличаться на одном и том же файле, а ведь теги при этом более гибки, чем любая иерархическая система.

      Так что получается что один человек разобраться во всем не сможет, а много создадут не то что нужно отдельным представителям. И будет действительно, аккуратно, красиво, но непонятно как найти.
  • +1
    А как быть если компов в доме > 1? Сдается что бесить будет развертывание-настройка всего этого хозяйства…
    Да и что делать со 100500 файлами которые уже есть? Вручную теги им выставлять?
    • +1
      Если вы внимательно читали статью, то там упоминались автотеги. При запуске системы — индексация всего что есть (п. 1), далее можно пользоваться специализированным файл-менеджером (п. 4) и искать по тегам (пп. 5-6).
      В принципе систему можно запустить на нескольких компах, а потом дописать ее в п.8 так, чтобы при перемещении в пределах домашней сети метаинформация не удалялась.
      • +1
        Не понимаю все равно как индексация автоматически заполнит например это:

        — откуда скачан (урл, локальный путь с указанием имени компьютера, откуда он был скачан, либо имя данного компьютера, если он был создан на нем с нуля, плюс ссылка на оригинальный файл и его версию, если это копия или версия другого файла)

        Файлики то ведь у вас все равно уже скачаны и лежат локально, url-а откуда скачаны не знают, или там имени компа в вашей сетке. Значит либо вы этот тег ручками заполните, либо не сможете им пользоваться. Не прав?

        • +1
          Конечно, если файл скачан давно, нельзя узнать, откуда он взялся, придется пользоваться остальными атрибутами или заполнять вручную. Но и остальных атрибутов (человекопонятный MIME, имя файла, дата, размер, имя компа/локальный путь) вполне может хватить для поиска. Имя компа вообще нужно, только если их несколько. И узнать его средствами ОС легко.

          Кстати, демон должен интегрироваться с download-менеджерами браузеров и dc++/торрент-трекерами, чтобы отслеживать источники. Но это все решаемая техническая проблема.
          • +1
            и с wget и curl?
            • +1
              wget и curl можно обернуть другим скриптом, либо наложить свои патчи на них, это самая простая задача, по сравнению с тем, что софта, куда нужно интегрировать связь с демоном тьма и не во всех случаях возможно это.
          • +1
            Чтобы интегрировать программу со всеми программами (даунлоадерами), а не только теми, что есть у тебя на компе в текущий момент, нужно туева куча работы. И даже если делать прогу только для себя и своё ПО, при появлении нового софта, который что-то скачивает, нужно его дорабатывать под этот демон (что не всегда возможно будет, если ПО закрытое или не имеет плагинов), либо жить в коробке и пользоваться только тем, куда смог интегрировать связь с демоном.
            • +1
              Снифать трафик?
              • +1
                Парсить заголовки HTTP и FTP трафика вполне реально. Или вопрос к чему-то другому?
              • +1
                Я как раз так и делаю:
                nmcap /network * /capture /DisableLocalOnly /File caput.cap
                если еще процессы отлавливать, то так:
                nmcap /network * /capture /DisableLocalOnly /CaptureProcesses /File caput.cap
                В конце дня скармливаю собранные капуты собственному индексатору, который синхронизирует появившиеся новые файлы на компе, и привязывает к закачанным урлам, сохраняя результаты в таблицу.
                Так же до-кучи вычисляются диффы по веткам реестра (но, это уже, к трафику не относится).
                • 0
                  А можно поподробней про индексатор, по какому принципу он связывает файлы и лог? (к сожалению нет под рукой винды, чтобы посмотреть как выглядит вывод nmcap'a, гугление не помогло). А то это кажется более менее нормальным способ определять, хотя бы какие файлы и откуда были скачаны.
    • 0
      Думаю если компов больше чем один, то данная система должна быть распределенной, то есть файлы будут лежать на разных машинах, вероятней всего будут доступны по разным протоколам, но находится в одной общей системе каталогизация и поиска. В случае чего компьютер просто рявкнет, что данный файл не находится в списке эакэшированных для мгновенного доступа, а компьютер источник не доступен, и предложит варианты решения (не открывать, удалить данную сущность, отцепить вообще данное хранилище)
  • +1
    Для тегов можно использовать атрибуты в ext3/4 и потоки в NTFS (так, насколько я знаю, некоторые атрибуты файлов в Windows и хранятся). Что касаемо демона — лучше сделать хуки на файловые операции. Правда, антивирусы могут не согласиться с такой реализацией.

    Я не очень хорошо знаком с Git (а честнее — плохо), но насколько я знаю, у него нет своей файловой системы, соответственно, все атрибуты будут храниться так же, как на «подлежащей» ФС, т.е. extN или NTFS. В сети попадалось упоминание о GitFS, но судя по тому, что попадалось, проект скорее мёртв, чем жив.

    В общем, дело только за файловым менеджером, который сложит это всё в одно целое.
    • +1
      Расширенные атрибуты в NTFS тоже есть, отдельно от файловых потоков. Называются они Extended Attributes (EA), подробнее тут: hex.pp.ua/extended-attributes.php
      • +1
        Extended-Attributes — они же и хранятся в файловом потоке, не?

        К статье:

        Пункт 1, кстати, винда выполняет самостоятельно, кроме, разве что, человеческого наименования mime, но она типы файлов различает и показывает разные иконки для файлов и, на сколько я помню — давно не пользовался семёркой, предлагает разные же элементы управления.

        Я даже думал самостоятельно написать такую программу для винды и хранить теги в специальном файловом потоке (Alternate Data Stream), но потом как-то перешёл на OS X, а для этой оси я программировать пока не умею :)
        • +1
          Extended Attributes на уровне файловой системы является отдельной сущностью по сравнению с alternate data streams. В MFT они хранятся в разных местах.
  • +1
    Вот будет весело, когда в Ваш порядок вторгнется посторонний человек (к примеру, новая девушка, желающая узнать больше о предшественницах).
    Порядок нужен только там, где предполагается разделенный доступ к данным, ради своего «эго» сортировать папочки и тегировать все фотки — непозволительное дорогое расходование личного времени и жизни. ИМХО.

    А за статью спасибо (+), это все можно внедрить на работе, где куча прототипов уже накопилась за несколько поколений разработки — вот там да — нужно какой-никакой порядок держать.
  • +1
    Мне навести порядок помогли три правила:
    1. Фотографии держаться в одной папке лайтрумом, все организуется им
    2. Музыка и видео лежат в своих папках на NAS'e. Причем в обоих есть подпапки 1 — обработанные и 2 — только что скачанные. Из второй они, бывает, мигрируют в первую. Иногда вторая злостно очищается.
    3. Очень часто что-то скачивается из интернета. Завел правило: все, что находится в папке загрузок можно в любой момент удалить. И периодически ее чищу. Если что-то действительно хочется сохранить, то я при скачивании сразу кладу в нужное место.

    особенно ценным считаю третье правило, т.к. до того больше всего страдал из-за засорения «загрузок»
    • +1
      LR — решение, пока снимков реально мало. Позже начинает тормозить :(
      • +1
        Эм… Давайте мериться снимками и конфигурациями компов. У меня там фотографий уже лет за 5, большая часть raw (все никак рука не поднимется удалить), поэтому гигов за 100, работает на toshiba a100-23v. Проблем не замечаю.
        • +1
          Да чего тут меряться, 100 Гб за 5 лет — это немного совсем, даже если не все в raw. Другое дело, что Вы в нем делаете, Вы же не только в роли Picas-ы его используете, или нет?

          Там внутри sqllite, это «объясняет» :)
          • +1
            Ну разумеется я и редактирую, и экспортирую фотографии оттуда. Там же просматриваю отснятое. Я согласен с тем, что LR не шибко быстрая программа, но если имеется мощный комп, она не тормозит. А у меня ноут то совсем старый, но даже с ним все хорошо. Поэтому и захотелось помериться, понять почему тормозит у вас.
            Кстати, чтобы не тормозил можно же придумать всякие обходы, например, организовать каталоги по годам, а не один на все.
        • +1
          У моей жены за 2 года больше 1,5 тб. LR тормозит безбожно. Правда помогает использование нескольких каталогов.
    • +1
      почти тоже самое
      музыка и видео лежат в /home/music, /home/video и доступны для чтения всем пользователям системы (ноут) на запись только мне
      домашняя станция по nfs монтирует /home/music и /home/video с сервера (роутер+xbmc) — это если хочется послушать/посмотреть на мониторе
      документы на всех машинах лежат в ~/Docs в которой подкаталоги работа/дом/
      все по телефонам(андроид) лежит в ~/android
      музыка сначала заливается в ~/music, а после правки тегов переносится в /home/music
      браузер все качает в /tmp (который автоматом чистится при перезагрузке) и если что то важное сразу переносится
      в нужную диру
      хоть и пользователь кде, но непомуком не пользуюсь. ибо постоянно шуршит винтом и занимает оперативку
      • 0
        Интересно, а есть пользователи KDE, которые пользуются nepomuk, помню когда KDE4 только была в разработки, это смотрелось как дар небес, типа у нас все будет круто, мета данные, все на месте, идеально можно все организовать, а как всегда получился пшик :(

        Как мне кажется ключевое в сохранение порядке у вас это то что все качается в /tmp
  • +3
    По-моему, раз и навсегда навести порядок в своих файлах можно только так:
    dd if=/dev/zero of=/dev/sda
    
    • +1
      а) без sudo не даст.
      б) наведёт порядок заодно и с операционной системой, если, конечно это один носитель
      • +1
        а) Оно и с sudo не даст, если пользователь не входит в группу wheel или не имеет особых полномочий. Зато если он входит в группу storage (или disk — смотря какой дистрибутив), то и sudo не понадобится.
        б) можно так «наводить порядок» только на разделах помимо системных ☺
  • +1
    Да, было бы хорошо!

    Но… «URL, откуда что скачано» — это было бы просто волшебно для всех, но — подобного рода теги проставляются, очевидно, прикладной программой, и вот тут и будет затык. Я, например, когда Firefox-ом качаю, а когда и wget — неужели и его патчить? А если без патча, то остается прописывать адреса вручную — тут меня ненадолго хватит :(
    • +1
      Очевидно, надо иметь плагины ко всем download-менеджерам, желательно использующим одинаковый протокол для общения с демоном.
      • +1
        В идеальном мире так и будет. :)

        Более того, там и плагины ни к чему: просто ФС сама будет знать, откуда прилетел в нее файл, ага. И у коллег-друзей на компах будет точно такая же ФС и тот же принцип тегирования, чтобы взятый «на посмотреть» файл не приходилось потом руками снабжать тегами. ;)
        • 0
          Вот тут возникает вопрос при копировании теггированного файла. В MacOS для этого используется механизм где вместе с файлом копируется второй скрытый файл хранящий в себе описание метатегов.
          Просто те же флешки и CD/DVD/BD болванки чаще всего имеют определенные ФС, в которые никак не вставшиь дополнительные плюшки с метаданными, если только без изврата, типа скрытых файлов, либо доп потоков, если флешка на NTFS.
          Да по сути это будут костыли, но мы живем в неидеальном мире :)
          Еще возникает вопрос как бы прописывать данные для файлов, которые выложенны где то на скачивание. Менять весь протокол скачивания файлов чтобы прицепить в конце хвост из метаданных?
          Как вариант давно думаю об идеи централизованного хранилища описаний файлов. Чтобы можно было получить метаданные по ключу файла (предположим связка размер+md5+sha1 будет уникально в таком проценте случаев что можно будет даже плюнуть на закон больших чисел), к сожалению возникает проблема в генерации описаний для таких файлов, с одной стороны могли бы помочь торренты, которых вон вагон и маленькая тележка, грабь описания, скачивай торрент файл, а в нем расписаны хэши по кускам, не так удобно конечно, но можно и кусочные хэши посылать и сравнивать то это или нет. Но тут возникает вторая проблема рубящая на корню цивилизованный вариант решения проблемы. Это то что если в торренте несколько файлов, то они по сути слепляются в один, и далее уже нарезаются на куски, вычленить где хэши конкретного файла уже получается нельзя. Так что остается только разве что решение в лоб. Скачивать все, раздавать до определенной цифры рейта, считать хэши, удалять, повторять. То есть широкий канал+терабайтный винт для временной помойки.
          • 0
            Ну, раз про идеальный мир, то проблема хранения мета-информации вместе с файлом вообще не должна подниматься — в идеальном мире все так и будет. Всегда. По другому — никогда :)

            А с описаниями фильмов (как пример довольно частый) — один «умник» напишет про фильм несколько общих фраз, другие у него воруют и у себя выкладывают. Так вот, качнешь файл с торрента, а там описание «никакое», и все наши умные («почти идеальные») схемы привязки описаний к файлам с треском проваливаются.

            Одно время (когда CD-диски были в ходу) была проблема, что к одному диску прилипала CDDB информация от другого, особенно если диски были российские, особенно — если не очень «правые» (скажем прямо — «левые»). Хеши — это класс, но не всегда спасет и он…
  • +1
    Музыка частично не каталогизирована, поэтому ищется или по тегам или по названия композиции.
    Фото коллекцией занимается Пикаса.
    Документы рабочие, личные, исходники проектов отдельно.
    Рабочая почта и бекапы отдельно.
    Видео чаще всего удаляется сразу после просмотра.
    Инсталляционные файлы рассортированы по типам — медиа, интернет, утилиты, офис, iso, игры.
  • +1
    nepomuk, не?
    • 0
      Привязан к Linux и KDE.
  • +2
    У меня есть отличный кустарный сопособ:
    1. все явно и неявно не нужное скидываем с папочку «свалка»
    2. если что-то не можем найти, ищем это в папочке «свалка» и если находим, кладем в нужное место
    3. через месяц очищаем папку «свалка» полностью (можно удалять лишь очень сратые файлы как вариант)
    Живу себе припеваючи. Знаю что если я не обращался к файлу дольше месяца (фотографии и музыка не в счет) то он мне нафик не нужен.
    • +1
      можно удалять лишь очень сратые файлы как вариант

      Какие-какие файлы? :)
      • +1
        старые =) крон поставить который будет удалять раз в день все что старше пары месяцев, и жизнь наладится.
  • +1
    А вообще, конечно, не хватает организованности в размещении всяких файлов. Зачастую проще скачать заново файл из сети, чем найти, где он находится локально.
    Еще полнотекстового поиска не хватает (но здесь приходится выбирать: либо хранить бешеную базу, да еще и распознавать все свои djvu/pdf без слоя OCR, либо оставить все, как есть).
    • 0
      Ага, когда имеется библиотека научная и художественная, на пол тб где-нито, а проще найти и слить в интернете, становится как то грустно. Распознование конечно хорошо, но думаю если умудрится для pdf/djvu, которые сканы привязать isbn, то дальше можно где нибудь автоматически задампить описание и оглавление, думаю этого уже хватит.
      Проблема с бешеной базой конечно имеет место быть. Помнится во времена Google Desktop считалось адекватным индекс порядка 30-50% от объема текстовых данный, это была одна из причин почему у меня оно не прижилось, несколько терабайт винтов требуют просто хамских объемов индексов. (я грохнул Google Desktop после того как он отожрал более 20 гигов на индексы, теперь то я понимаю что в принципе это было не так уж и страшно)

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

      Скорость поиска по такой базе имхо тоже должна учитываться. Поэтому приходим к тому что для начала нужно наплодить сущностей в бд. А файлы так, привязка к ним, ведь никому не нужны файлы. Ищут книгу, статью, песню, фильм, факт, а не файл с фильмом и т.д.
  • +1
    Для порядка на рабочем столе (Windows) советую Fences.
    • +2
      ИМХО рабочий стол не для иконок.
      • 0
        В Fences двойной клик по рабочему столу скрывает все иконки.

        Они мне нужны раз в год, я их показываю, открываю и снова скрываю. Очень удобно, честно
  • +2
    Как-то один мудрый человек мне сказал: чисто не там, где постоянно убирают, а там, где не гадят. Стараюсь придерживаться этого принципа и по сей день. Но пока, к сожалению, только на компе.
  • +5
    Можно ли прибраться на компе раз и навсегда?

    нет.
    • +1
      Потому что, файловая структура работающего компьютера — вещь динамичная. Навсегда можете это делать, если один раз сортируете и больше не работаете на этом компьютере.
  • +2
    На самом деле обычно проблема находится не в тэгах и интерфейсах, а в головах. Именно там, в голове, должен быть порядок. У большинства там порядка нет, и тогда никакие тэги не помогут.

    Ещё нужно немного воли — чтобы заставлять себя поддерживать на винте тот порядок, который советует голова, а не валить всё в одну кучу. А если всё-таки кучу навалил — чтобы заставить себя её разобрать. Примеры использования воли есть в предыдущих комментариях.

    Если и с головой и с волей всё хорошо, тогда в дело вступают индивидуальные отличия — кому-то проще думать иерархически, а кому-то тэгами. Лично я тэги не понимаю — от автоматического тегирования толку мало, а вручную тегировать так, чтобы это действительно работало — задолбаешься (я про обычные файлы, разумеется, для всякой мультимедии тэги работают отлично — кстати, в значительной степени потому, что для вас их уже прописал кто-то другой). А с иерархией в нечастых случаях когда нужно иметь несколько путей к одному каталогу/файлу помогают симлинки. А в сложных — /usr/bin/find.

    Что касается версионирования, то git (и вообще VCS) для этого не лучшая идея, здесь скорее нужны файловые системы поддерживающие монтирование в состоянии на любой момент в прошлом.
    • –1
      Не так плохо, если думать будут за меня.
      И думать будут обо мне, как мне удобно и понятно сортировать и выставлять теги.
    • НЛО прилетело и опубликовало эту надпись здесь
      • 0
        Как хранится информация в голове не имеет отношения к тому как удобнее огранизовывать файлы на винте. А удобнее всем по-разному, и это нормально. Нет смысла навязывать тэговую структуру всем — ведь лично Вам бы не понравилось навязывание иерархической, верно?
        • 0
          Устраивающий всех выход, наверное, «графовая» или «реляционная» ФС — позволяет «эмулировать» как иерархическую, так и теговую. Плюс позволяет реализовывать множество других принципов упорядочивания.
          • 0
            реляционная структура, как и графовая создает проблемы в плане того как делать интерфейс. Современные интерфейсы заточены под иерархическую либо теговую систему организации данных, и я бы не сказал что графы из Personal Brain удобней. Да можно хранить все в виде кучи параметров, а затем делать конкретные срезы, вот только непонятно как для этого сделать удобный интерфейс.
            Еще бы конечно хотелось чтобы старый софт направленный на иерархический просмотр, мог работать с такими данными. Когда делал свой похожий велосипед, то использовал Fuse плюс различные реляционные срезы представляли из себя папки верхнего уровня, но не сказать чтобы это было слишком удобно.
  • +3
    Я вообще не понимаю проблемы свалок. Ставишь программу — ставь ее в Program Files, а не корень игры в в Games (по желанию), музыка/кино в соответствующую папку. Диплом — мои документы/диплом, Рабочие проекты — мои документы/visual studio 2010/projects. И так далее. А если есть папка с тысячими скачанными файлами — да удалите их нафик, все равно уже новые версии наверняка вышли, а верояность остаться без интернета, чтобы не перекачать, когда понадибится — крайне мала (с)

    Алсо, вся музыка и так давно вконтакте (я использую savefrom.net скрипты, они показывают битрейт — слушаю 320 без проблем), а кино —TorrentStream, даже не скачиваю, смотрю напрямую. Сериалы — турбофильм. То есть на диске остаются только прогрммы, да рабочие файлы — как тут-то бардак можно устроить?

    Правильно написал powerman — бардак если и есть, то в голове, ибо можно и в тегах бардак устроить =)

    • +3
      Пользоваться предлагаемыми по-умолчанию папками — путь к ещё большему бардаку.
    • 0
      Держать всю мультимедию онлайн идея неплохая, но во-первых не всегда это возможно/удобно, а во-вторых текущие реализации пока слабоваты. Конкретнее:

      — Я не верю в беспроблемное существование сайтов, которые предоставляют юзерам возможность бесплатно и без рекламы смотреть/слушать всё то, что качается с рутрекера (плюс по мелочам рутор для того контента, который с рутрекера удалили правообладатели).

      — У меня акустика качественная, поэтому разницу между mp3 320kbps и lossless я отлично слышу. Так что музыка — только в flac. ВКонтакте я не зареган, как и в прочих фейсбуках. И хотя инет у меня последний раз пропадал уже не помню когда (на то дома два провайдера подключены), но всё-равно, идея остаться одновременно без инета и без музыки — пугает. В общем, на мой взгляд оптимально было бы комбинировать — часть музыки держать локально, часть слушать онлайн (конечно, если существуют сервисы на которых дают всю нужную музыку в flac, причём желательно не в браузере, а в моём плеере).

      — Фильмы/сериалы иногда нужно всё-равно выкачивать для записи на болванки и передачи родителям для просмотра на DVD-плеере. Так что одним онлайном не обойдёшься.

      — Смотреть фильмы/сериалы прямо в процессе выкачки торрента — идея здравая. Но вот что касается реализации — TorrentStream не в курсе, что помимо винды есть и другие ОС; на турбофильме закрыта регистрация, так что я на него даже посмотреть не могу. Вообще, на такого рода ресурсах нет ни малейшего желания регистрироваться, я уж молчу про охоту на инвайты — покажите мне сначала, что этот сайт мне реально полезен, потом объясните чем он может стать ещё удобнее если зарегистрироваться, плюс желательно сделайте поддержку OpenID — вот тогда я задумаюсь о регистрации, не раньше. Из отзывов в инете — насколько я понял, качественной (т.е. гига 3+ в h264 на фильм) поддержки 720p на таких сервисах обычно нет.
      • 0
        — ну контакт живет уже ооочень давно и будет жить. Пашу явно кто-то прикрывает сверху, судя по его обращениям ко всевозможным органам и вообще выходкам. У нас очень немногие себе такое позволяют.
        — ну да-да, я раньше я тоже законялся по флаку, но возможность слуашть онлайн, так еще и рекомендуемое (спасибо seesu.me/o) прямо из контактика взяла верх. Хотя, конечно, про разницу 320 и FLAC готов на ящик пиво поспорить на самом деле. 128/192, возможно 256 и я слышал. Но 320, хмм, возмонжо, если только вы уникум.
        — ну выкачали, записали, удалили. Никакой свалки=)
        — Да, под невиндами торентстрима нет, но многие клиенты и так умеют стримить — юторрент может, кажется маковское что-то тоже (девушка моя вроде стримила), так что не TS единым.

        Хотите инвайт на турбик? ;-) Он классный.
        • 0
          320/flac — как я уже сказал, это вопрос качества акустики. на компьютерных колонках разницу услышат разве что аудиофилы. а на hi-end аппаратуре разница слышна невооружённым ухом, в т.ч. при двойном слепом тестировании и без всякого аудиофильства. Слух у меня не абсолютный, но хороший — музыкой несколько лет занимался в детстве. Так что на уникума я не тяну, но на качество звука внимание обращаю.

          Инвайт — нет, спасибо, но не нужен. Мне турбик мотивацию для регистрации не создал пока.

        • 0
          Ага, лень берет свое =)

          Слушаю музыку с ютуба, я.музыка, ооочень редко контакт.

          На плеер заливаю 256-320 (все равно на затычках ничего нормального не послушаешь, даже на хороших).
          Если сильно зацепила музыка — качаю флак и слушаю на компе. К сожалению не так уж много «неодноразовых» мелодий…
          • 0
            На Cowon J3 и минимальных наушниках вроде Koss (Sporta|Porta) Pro разница между flac и mp3 320 вполне заметна. Что касается «не одноразовых» мелодий — это смотря что слушать. Если попсу — согласен, если русский рок — там одноразовых почти нет вообще, все любимые группы слушаются целыми альбомами годами.
  • +1
    Давно думают и давно обещают, но пока хороших решений нет.
    Да и кроме того, кроме функциональности, хотелось бы лишний раз не думать и не делать лишних движений. Взять-перетащить-скопировать. И быстро. И не громоздко. А уж когда понадобится… то и функции доставать.

    Думаю, в недалёком будущем в облачных решениях будут уже рабочие механизмы.
  • 0
    Как говорится, чисто не там, где прибирают, а там, где не мусорят.
  • 0
    Фотки и написанные мной код/тексты/etc. прекрасно распределяются по своим каталогам еще на этапе скидывания/создания. Для резервного копирования — git (если сам что-то поломаю) и dropbox (если поломается что-то само).
    Куда будут ставиться программы и где будут лежать их конфиги — забота их разработчиков. Если мне понадобится эта информация — ее можно нагуглить за 15 секунд, использовать, и тут же забыть.
    Скачанное же проще скачать заново, чем искать в Downloads. Да, это приводит к появлению там файлов с именами вида problems(156).pdf, но тут ничего страшного нет.
  • 0
    Тема интересная. У вас какие-то наработки есть? Занимаюсь уже несколько лет разработкой технологии чем-то перекликающейся с вашими «тегами» и «версионностью», у меня правда все ориентировано на облака и энтерпрайз и это скорее специальный вариант базы данных (в смысле NoSQL) поверх которых навернуты некоторые приложения для энтерпайза. Сильно подробностями делиться не могу. Ваша статья заставила меня задуматься о технолгии, как о файловой системе.
    • 0
      Посмотрите инфу по WinFS может ещё какие деи почерпнёте.
    • 0
      Эта статья — просто ТЗ для реализации желающими. Сам пока занят другими проектами.
      Идей всегда больше, чем возможностей их реализовать :(
  • 0
    Все папки по работе хранятся на ноутбуке и распределены на текущие и архивные. Для каждого своя папка.
    Все загрузки скидываются в одну папку.
    Если не можешь что-то найти, то стандартный Spotlight в Lion ищет по всем документам, почте и т.п. (содержимое тоже просматривается) за доли секунды. Правда перед этим может час мусолить диск, индексируя.

    А на домашнем компе программы в программы, игры в игры, а все остальное как временное в Загрузки (расшарена). По мере просмотра/прослушивания/прочтения/проиграния удаляется.

    Все можно найти. Бардака вроде нет.
  • +1
    Я знаю единственный эффективный инструмент для наведения порядка — форматирование и удаление, начало с белого листа.
    Любая система организации со временем превращается в ту же помойку.
    Дело в самоорганизации и приучении себя к порядку.
    • 0
      Я примерно так и делаю. У меня винт «нарезан» на разделы 32 ГБ (FAT32), на которые сливаю все без разбора.
      Когда раздел заполняется под-завязку, удаляю все дубли с раздела.
      Когда (после очередного удаления дублей) на диске не прибавляется места — ищу на нем самые крупные файлы и их перетаскиваю на второй раздел (где складируются только крупные файлы).
      Когда переполняется раздел с крупными файлами — беру 7 чистых DVD-R (цена вопроса 70 рублей) и сливаю все крупное туда и форматирую.
      Когда все 32 ГБ на первом диске заполняются «уникальной мелочью» (например 100500 фоток), на NTFS-разделе (да-да, у меня просто когда почти все буквы алфавита заняты под FAT32-разделы, и приходится остаток диска форматерить под NTFS) я создаю виртуальный VHD-диск размером в 4 гига (форматирую его в NTFS, с использованием сжатия для экономии места, и отключенной индексацией), и сливаю туда под-завязку всякую мелочь (освобождая место на первом диске). Потом, отключаю переполненный VHD, создаю еще один такой же, и повторяю итерацию.
      При этом, на «первом» диске (благодаря особенности файловой системы) высвобождается гораздо больше места (чем сумма размеров VHD-дисков).
      Со временем, NTFS-раздел с кучей VHD-дисков тоже начинает постепенно переполняться.
      Тогда я беру внешний винт — и сливаю на него все накопившиеся VHD-тома (и форматирую NTFS-раздел).
  • +1
    У меня была идея при индексации производить поиск в Google, КиноПоиск.ru и т.п. и затем по запросу быстро выдавать найденную информацию и давать возможность переименовать файл на основании найденной информации.

    Но это в будущем, а пока пришел к тому, что сделал скрипт на питоне, который производит поиск по каталогу Downloads, ищет файлы и одноименные .torrent файлы. Затем берет из .torrent файла URL странички на rutracker.org, загружает эту страничку и получает название закачки.
    Затем, на основании полученного текста, скрипт переименовывает скачанный файл.
    В итоге вместо "God.Bless.America.2011.HDTVRiP720.mkv" я получаю файл с именем
    "Боже, Благослови Америку God Bless America (Боб Голдтуэйт Bobcat Goldthwait) (2011) США, триллер, чёрная комедия, криминал, HDTVRip-AVC.mkv".
  • +1
    Да, актуальная проблема. Решаю двумя путями: софт + дисциплина.

    Софт:
    — Everything. www.voidtools.com/
    Суть: сканирует файловую систему (только имена файлов!) Работает постоянно в фоне, вызывается по хоткею, работает очень быстро, комп не тормозит, ищет моментально. Поиск по именам, с масками, с регэкспами.

    Дисциплина:
    — Весь хлам в d:\razgrebat Там же каталог downloads от браузера и торрентов. Туда попадает почти все новое. (Исключение — фото. Но для них тоже свой «razgrebat», пусть и в другом месте)
    — Каждый день каталог downloads должен оставаться чистым. Т.е. скачал что-то — разберись с ним и пойми, нужно или нет. Скачал «на будущее» — положи в нужное место, где потом найдешь и назови так, чтобы нашел. С этим больше всего проблем, нет времени постоянно. Но раз в неделю подчищаю наверняка.
    — То, что точно знаю, что пригодится, но сложно понять, в какой каталог положить и есть сомнения, что смогу найти, ложу в какой-то один, но меняю имя файла и указываю несколько возможных «тегов», так, чтобы точно нашел. Например, вполне может быть такой файл: «auto avto авто машина accent.xls», где зафиксировано, когда и какие расходники менялись, и когда это пора делать. Хотя подобного типа файлы постепенно переходят в Evernote.

    Ну и еще плюс в сторону порядка: бекап проходит куда легче и нужно бекапить меньше. У меня настроен бекап в облако (CrashPlan): порядок спасает.
    • 0
      Да, только дисциплина поможет навести порядок. Для меня самый лучший инструмент для наведения порядка — это Total Commander. Обычно когда скапливается хлам, а скапливается он в папке «Downloads», то просто раскидывается по категориям (папкам), фильмы идут в фильмы, музыка в музыку, пепел к пеплу, прах к праху. В качестве «чистилища» временные папки также могут находиться на рабочем столе. А там они либо перемещаются в корзину, либо остаются на компьютере, если это что-то нужное.
  • 0
    Вот бы онтологию Drupal прикрутить к ext*…
    • 0
      Идея интересная, я даже как то видел модуль для друпала как раз для того чтобы делать репозитории файлов, с онтологиями и т.д.
      Вот только основная проблема как я уже в этой теме писал в том что тут нужно переходить на Entity как основу хранения, а файлы должны быть так, дополнением, типа этот файл представляет из себя вот эту Entity, а этот идет дополнительно к ней. Entity на каждый файл бред. :(
  • НЛО прилетело и опубликовало эту надпись здесь
  • +1
    Займусь ссылко-постингом, поскольку подобные обсуждения уже не раз всплывали на хабре, и возможно в спорах дня прошлого получится найти что нибудь интересное для дня нынешнего.
    Для начала касательно спора теги против иерархии. ^_^

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

    А теперь немного ссылок на предыдущие комменты чтобы не перепостивать их раз за разом :)

    Мой коммент к статье Проблемы, подстерегающие любого создателя рубрикаторов

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

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

    В подходе f2 — save, ctrl+f2 — commit существует громадный минус, он требует переписывания софта. Те же яблочники внедрили версионность для документов в Lion, но к сожалению не весь софт это поддерживает, да и работа с предыдущими вариантами не всегда удобно. (например я хочу оставить только последнюю копию, и удалить все предыдущии, у меня нет нормального способа это сделать, или я хочу версионность только в отдельных приложениях).
    По сути тут два пути либо это все каким то чудом работает автоматически, либо же необходимо переписывать по.
    Автоматический путь может быть из разряда делаем автоматические коммиты файлов при изменение, пока не будет занять n%, затем например все файлы больше m% или x мегабайт. Но это все равно будет создавать кучу ненужных копий, можно плюнуть на репликацию всех файлов больше x мегабайт, но те кто работают с видео, могут не оценить наш юмор ;)
    При этом не надо забывать про всякие редакторы с автосохранение каждые n минут, и торренты, и если вся история редактирования файла, вплоть до нажатия Save еще может пригодится, то каждые n минут реплицировать загружающийся торрент имхо плохая идея.

    Таким образом идеальной будет система, которая будет изначально спроектированна для этого, ось, софт, фс, это очень сложно сделать по отдельности. Если же это будет полностью готовая система, мы получим светлое будущее, а также мертворожденный проект, так как софта нет, а писать его никто не будет :) А портировать готовый это шаманство, ибо кто будет сохранять мета-данные? То есть идем на компромиссы, в итоге пользователь получает, что часть файлов у него пишется с кучей мета-данных, часть просто валяется, часть индексируется хорошо, часть нереально найти и непонятно где оно лежит. Результат закономерен, большинство пользователей этим пользоваться не будет.
    В KDE Nepomuk великолепная идея. Но они не учитывают что такая система пользователю нужна как что то цельное. А не как эта программа работает с метаданными, эта нет, зато она не тормозит и красивее, ну и на кой мне эти метаданные? :)

    Вообще на самом деле концепция файла само по себе никому не нужна, ну файл и файл, какая разница как оно хранится, но нам всем будет очень сложно переходить на концепцию сущностей, когда это не mp3 файл, а песня, не mp3 файл — а запись разговора, не текстовый файл, а субтитры привязанные к фильму. Имхо такая концепция имеет больше прав на жизнь, и она скорей всего придет, правда вероятно всего не для нас.
    Эта концепция налагает некоторые ограничения в плане каталогизация, но имхо даст гораздо больше гибкости и удобства, но вот не могу я представить нынешние программы в этом интерфейсе, это нужно также все переделывать, а соответственно пока что это не жизнеспособно. :(
  • 0
    Может выбросить нафиг папки и сделать просто «Все картинки» и «Все документы»? Добавить версионность, теги и удобный интерфейс?
  • 0
    Когда-то давно, когда я работал на компе с винтом 40МБ, на нём была тыща файлов (~1000 шт) и я знал их все. И был порядок.

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