Идеи по иерархии и именованию файлов?

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

Поэтому лучшим методом будут каталоги по типам (видео, музыка, графика), а в них - по темам (группы, жанры и так далее).

Приведи пример, чтобы было нагляднее.

Просто сделай как можешь и всё.

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

категории в таком деле не катят. только тэги, только такой фс, что вместо директорий тэги имеет, я не знаю

опередил

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

У меня например обычно сортировка по типу, а затем по имени. И по этому у меня выглядит следующим образом список:

• _dwnld
• _musik
• _vm
• docs
• foto

Конечно, это скорее ещё одна защита от дурака. Но мне кажется лишней не будет.

для работы с контентом файловые системы ненужны. Нужны метки: выбрал я «2011» год - отобразились все документы за 2011 год, выбрал «металлолом» - отразились все документы по металлолому за 2011 год, вбираю «Краснодар» - отражаются все документы по металлолому в Краснодаре в 2011 году

А чем тебе каталоги не теги?

Скорее уж ссылки это теги.

Ссылки бывают и жёсткие.

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

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

Хардлинк файла в обе категории (каталоги). То же самое, что и теги, но на уровне ФС. Это, конечно, неудобно всё время лезть в консоль, так что дело только за созданием удобного интерфейса для работы с линками.

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

Нет, он изменяется. Хардлинк это всего лишь ещё одно имя файла, все они ссылаются в один файл.

хардлинки не катят потому что работают в пределах одной фс

Вот это да, это недостаток. Существенный.

Теги противоестественны и не нужны. Нужно

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

что вместо директорий тэги имеет

симлинки это сила, симлинки это класс!

для работы с контентом файловые системы ненужны. Нужны метки: выбрал я «2011» год - отобразились все документы за 2011 год, выбрал «металлолом» - отразились все документы по металлолому за 2011 год, вбираю «Краснодар» - отражаются все документы по металлолому в Краснодаре в 2011 году

поздравляю, вы изобрели семантический десктоп

Хардлинки на каталоги потенциально приводят к проблемам.

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

Идеи по иерархии и именованию файлов? (комментарий)

1. Симлинки. Сложность в их контроле. 2. Тегирование. Сложность в заполнении этих тагов, а если файлов дофига...

Решения уже имеются в конечном софте: плееры, библиотеки и т.п. В итоге единственный путь для тебя - написать плагин для mc, far и т.п. :)

Up: есть еще решение - своя файловая система, но думаю, ты не осилишь.

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

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

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

Вообще нынешная система расположения файлов уже является законченным решением задачи как хранить и отображать файлы. Твоя же задача создать совершенно другую модель отображения файлов. Как хранить, отображать и искать документы уже известно - ищи работы по поиску документов в сети интернет (каталоги, поисковики и т.п.). Таких работ масса. Смысл один и тот же, только объекты разные (вебсайты vs файлы).

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

я тоже когда-то парился этим вопросом. Потом забил. Теперь у меня просто Musik, Video, Downloads, Documents, а все остальное в ~.

файлы именую по-русски, если название русское, по-английски, если английское и по-немецуи, если немецкое.

слова разделяю пробелами.

Часто пользуюсь locate.

с комментариями я бы не парился. Они нужны в самых редких случаях.

Можно начать с патчинга любой fs: всего-то добавить несколько своих полей

Так у ext* уже сто лет есть расширенные атрибуты. Чем не катит?

а куда предлагаешь, например, фильмы засовывать, в которых к примеру есть и драма и комедия?

В /dev/null

кстати, погляди в сторону strigi, а потом в сторону nepomuk.

Решения уже имеются в конечном софте: плееры, библиотеки и т.п

А вот решений на уровне системы почти что нет. Ситуацию в порядок приводит только семантический десктоп. Если учесть, что в KDE программы сами не играют музычку и не открывают ODT, а задействуют kdelibs, то вообще не возникнет вопроса вроде.

Теги и оценки ставятся автоматически на основе совершенно посторонних действий пользователя вроде нажатия кнопочки переключения на следующий трек на клавиатуре - причём речь идёт не просто о +-1 при каждом переключении.

Зачем хардлинки на каталоги?

Оба варианта чуть менее чем полностью бесполезны. Только память жрут.

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

На часть все-таки отвечу:

Например нужно ли делать дерево каталогов с большой глубиной или же с малой, но размещая в каждой директории множество файлов?

С удобной/естественной тебе, очевидно же. Удобная мне кому-то глубока, кому-то недостаточна.

Как решать вопрос, когда по смыслу файл подходит в два места каталога? Вручную прокидывать сим/хардлинки?

В два разных каталога? Пришла пора пересмотреть иерархию, че тут. А то бардак будет, в голове, ФС и делах.

Стоит ли складывать все файлы, доступ к которым хотелось бы иметь из-под разных пользователей/ОС (музыка, фильмы, книги) вне /home или же всё-таки класть в /home и chmod'ом расшаривать доступ?

На сетевую шару или нечто с ней синхронизируемое :) Когда ты это захочешь синхронизировать себе на новый ноут/мобильник/планшет/что-сейчас-еще-в-моде, попомнишь мои слова, дуалбутчик.

Chmod'ом расшаривать доступ --- сам-то пробовал? Тут целый bindfs нужен, тормозный, кстати, донельзя.

Выбирая из твоих вариантов - вне /home очевидно и на отдельный раздел, т. к. в .../корень_одной_из_систем/home лежат пользователи конкретной системы, а ты предлагаешь туда поместить файлы, по логике принадлежащие аж к пользователям разных СИСТЕМ. Lanyardfs как раз анонсировали, чтобы bindfs не юзать.

Как быть с файлами, полученными через торренты, которые обычно хочется переименовать/переместить, но при этом сохранить файл на раздаче? Опять же вручную прокидывать линк?

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

Чуть ли не самый важный вопрос: как писать комментарии к файлам на уровне файловой системы? Создавать текстовый файлик и класть его рядом с файлом? Но для этого придётся каждый одиночный файл прятать в отдельную директорию, чтобы комментарий был рядом.

Зачем?.. Лобовое решение:

A_file_that_needs_a_comment_for_some_lame_reason.img_inside.abiword.gz и A_file_that_needs_a_comment_for_some_lame_reason.img_inside.abiword.gz.COMMENT

Да и часто ли надо комментировать одиночные файлы? И файлы вообще? Путь к файлу --- вот лучший к нему комментарий.

Как решить вопрос с отображением комментария напротив файла в команде ls -l? Писать свой враппер-велосипед?

Порвать, завязать, телефон дилера выкинуть, друзей просить пристрелить, если сорвешься. Комментарий к файлу это еще ладно, но такой вопрос и ставить-то не надо, не то что решать, dear Mr. Poettering.

Пользуй метки и не парься.

Добро пожаловать в наш клуб!

Хорошей литературы не нашел. Вот вот измышления:
1. Если много файлов, то система структурированного дерева каталогов - плохой инструмент для хранения файлов. Даже с хардлинками/симлинками. Нужна система тегов.
2. Главное правило при хранении информации - осмысленное название, потому как самый эффективный алгоритм поиска таков: 1) заходишь вручную на 1-2 уровня иерархии (например, data/docs), а потом поиском находишь то, что конкретно тебе нужно.

Что использую я:
- Я придумал нормальную структуру каталогов для софта, домашнего каталога, фотографий (здесь уже есть вижу пути улучшения). Критерий нормальности: 1) быстро нахожу то, что ищу; 2) нет эффекта когда добавляешь новые файлы, а потом узнаешь, что они у тебя уже есть (лет 5 назад уже зкачивал), но они лежат в другом месте.
- Я начинаю использовать систему тегов для данных; это пока в зачаточном состоянии, но уже приносит плоды - находить намного проще.
- При размещении фоток активно использую хардлинки. Для этого есть облегчалка для mc. Могу поделиться.

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

для большей безопасности ценных данных применять такое соглашение именования

Такое ощущение, что это рецепт из журнала домохозяек. Ржака.

Оба варианта чуть менее чем полностью бесполезны. Только память жрут.

обоснуй.

быстрое нахождение файла

Подтверждается опытом знакомых, которые за секунды находят нужное, следующая система именования

├── !!!фотографии
├── !!фоточки
├── !фотки
├── 1
│   └── StarCraft1
├── 2
│   └── !посмотреть!
└── 3
    └── привезённое

помойка лучше всего

Зачем хардлинки на каталоги?

А как ты собираешься теггировать каталоги? Допустим музыкальные альбомы.

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

Допустим музыкальные альбомы

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

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

/home/denis

/home/denis/Видео

/home/denis/Видео/Порно

Ну и так далее, чего мудрить-то?

потэгать каждый файл именем альбома

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

С тебя смайлик!

Как быть с файлами, полученными через торренты, которые обычно хочется переименовать/переместить, но при этом сохранить файл на раздаче?

Пользоваться торрент клиентом, который умеет перемещать файлы

ты какой-то непонятный. я за тэговую фс

>как писать комментарии к файлам на уровне файловой системы?
user_xattr [pokerface.png]

>Например нужно ли делать дерево каталогов с большой глубиной или же с малой, но размещая в каждой директории множество файлов?
Нужно делать столько, сколько достаточно на данный момент. Как только глубины окажется мало — добавишь и переместишь нужные файлы куда надо. Серьёзно. Ну а так, категория/раздел/жанр и/или автор (в зависимости от). Далее, если нужно, добавляешь разделы для частей или сезонов, если они есть, потом можно и персонажей, если вдруг такая нужда. Было бы желание и необходимость.

проблема древовидной иерархией не решаема. надо переходить на графовидную структуру данных.

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