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

Ремесло архивариуса умерло с последним представителями или скатилось в СГ.

Юзай локальные индексаторы.

NEPOMUK же )

Всё зависит от того, по каким критериям ты хочешь искать файлы.

Выбери логичную иерархию директорий и как можно более подробную.

Если не поможет, то юзай локальные индексаторы (как подсказали выше), тот же Непомук из состава KDE4, ибо гномовский трэкер до сих пор сыроват (вчера пробовал).

Если использовать иерархию директорий, для доступа к файлу придется пробираться через 100500 вложенных директорий... Автоматическая индексация зачастую невозможна (скажем, документ не содержит текстового слоя, или же это - фотография)...

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

Не устраивай свалку на винте и ничего искать не нужно будет

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

>Если использовать иерархию директорий, для доступа к файлу придется пробираться через 100500 вложенных директорий...

scribus pro<tab>la<tab>Ya<tab>moti<tab>moti<tab>

Итого менее 5 секунд для доступа к файлу ~/projects/layouting/Yamaha/motifrackxs/motifrackxs_en_om_b0.sla.gz

По мне, так порядок на винте все решает

++ Но как порой удержаться сложно.
У меня есть два вида tmp-а. Первый: файло лежит на рабочем столе и разгребается по мере намозоливания глаз. То что не нужно, удаляется, а то что я считаю хоть немного полезным (адреса вкладок в огнелисе котороые хотелось бы сохранить на потом, книги, картинки, фотки, документы и пр.) переходит во второй temp, находящийся в глубинах хомяка. Там уже файло валяется месяцами.
Порой, видя это огромное количество файла, руки опускаются его разгребать.
Ничего не могу с собой поделать. :(

А когда файлов - многие тысячи?

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

Люто, бешено плюсую.

Плюсую иерархию директорий.

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

5 уровней директорий по 3 в каждой дают уже 243 директории, так что не будет 100500 вложенных. А вообще можно и поддержку тегов сделать, создать еще папку с 1 уровнем папок тегов и в ней хардлинки наставить.

>А когда файлов - многие тысячи?

Ну, у меня их и есть многие тысячи:

nixon@gnunixon:~$ ls -lR |wc -l

192024

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

Ага. И размещение каждого нового файла превратится в получасовую борьбу с ln :)

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

>Ибо некоторые материалы, могут логически относиться к разным категориям

Хардлинки

>А если захочется таким образом реструктуризовать уже имеющуюся файлопомойку, вообще не представляю, сколько времени убить придется...

Зато время убить придется всего один раз, потом это сильно облегчит тебе жизнь.

ishtar> 03.05, 11:35 ~/Docs
ls -lR | wc -l
30321

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

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

Это костыль.

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

Да, да, костыли спасут жертву вражеской мины. :)

Тогда уж проще в этом «супер скрипте» использовать sqlite для хранения тегов к каждому файлу.

> Тогда уж проще в этом «супер скрипте» использовать sqlite для хранения тегов к каждому файлу.

а суперскрипт перенос/переименование/удаление отслеживать будет?

А как вы в случае с хардлинками то же самое будете делать?

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

http://lorquotes.ru/view-quote.php?id=1058

А зачем использовать sqlite? Базы данных не так уж мгновенно работают на сотнях тысяч записей. Да и здесь не нужен ни SQL, ни всякие другие фичи баз данных. А поиск файлов можно будет осуществлять стандартными средствами.

С хардлинками перенос и переименование ничего не значат, только для удаления надо будет еще написать скрипт с использованием find.

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

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

Поэтому спасти может только введение метатегов для тегов. ;)

Ага. И опять-таки, костыли с просмотром всех тегов для данного файла...

Все теги можно посмотреть через find с именем файла.

> А как вы в случае с хардлинками то же самое будете делать?

без ФС с поддержкой тегов ничего не получится.

inode + inotify, только конечно не в виде скрипта

> А зачем использовать sqlite? Базы данных не так уж мгновенно работают на сотнях тысяч записей.

да ну - есть способ более быстрый чем доступ по смещению?

ни всякие другие фичи баз данных

индексация не нужна?

Ну, не знаю. Я как-то давно в пикасе пытался организовать нормальное хранение своих фотографий, посредством введения тегов для каждой фотографии. Где-то после 3-4 сотен фотографий меня это достало. Но смысл вполне удобен. Например, вводим теги для фото: «морды», «природа», «жЫвотные», «мусор», названия мест фотографирования, имена отображенных «морд» и т.п. Тогда в теории будет легко (если, конечно, несколько десятков тысяч фото сначала правильно проиндексировать) найти, скажем, все фото человека А в месте Б и позе В :)

Точно так же и с файлами. Но работа по первоначальной организации самого хранилища колоссальна. И делать ее вряд ли кому захочется. А вот новые файлы, конечно, можно сразу же было бы «подписывать», особенно если добавлять их понемногу...

man locate

Мое решение: два раза в год устраиваю генеральную уборку. Показательно что 90% скачанного стирается за ненадобностью. Остальное (книги, музыка) изнчально кидаются в директории /books , /music

С этой стороны БД конечно быстрее работают благодаря индексации. Но в БД поиск по соответствию тега - файлу будет идти по таблице где будет соответствие каждого файла каждому тегу, а по ФС только по списку тегов. А если еще добавить регэкспы, то неоднозначность еще увеличится.

same shit, bro

> Но в БД поиск по соответствию тега - файлу будет идти по таблице где будет соответствие каждого файла каждому тегу,

для такого можно использовать стандартное расширение SQLite:

http://www.sqlite.org/fts3.html

Можно и это использовать расширение. А можно locate, как выше сказали. Вероятно есть больше одного пути чтобы сделать это.

cd туда,_не_знаю,_куда; find/locate то,_не_знаю,_что :)

вот для этого я сделал нормальную файловую иерархию и вменяемые имена :)

можно пример того что у тебя получилось?

Ага. И размещение каждого нового файла превратится в получасовую борьбу с ln :)

достало именно необходимость при создании файла создавать определенное количество симлинков в дереве

у меня получились директории с вложенными директориями и файлами %)

> через некоторое время понимаешь, что в тегах у тебя такой же срач

Поэтому спасти может только введение метатегов для тегов. ;)

Достоинства тегов против ФС в том, что они не связаны в дерево и произвольная единица может иметь более одного тега.

А срач можно и на ФС развести.

Посоветуй рабочий индексатор.

>>Достоинства тегов против ФС в том, что они не связаны в дерево и произвольная единица может иметь более одного тега.

Да? Спасибо, конечно, что просветил.

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

Начни с того, что не храни ничего ненужного.

+100500

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