Существует ли это: стандартизированный способ документирования структуры файловой системы

На работе я отвечаю за поддержание организации множества различных данных в стандартной файловой системе. Часть этого заключается в разумной классификации (по сходству, необходимости, доступу для чтения / записи и т. Д.), Но большая часть фактически документирует это: какие документы / файлы / носители должны быть расположены, а какие не должны находиться в этом каталоге, "что-то немного другое, см. ../../other-dir" и т. д.

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

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

Итак, позвольте мне предложить лучшее решение, и, надеюсь, вы можете сказать мне, если оно существует. Любой каталог в любой файловой системе может иметь скрытый текстовый файл с именем .readme. Его содержание является описательным человеческим языком. Он использует некоторую разметку, например Markdown, с чуть более жирным, курсивом и (относительными) гиперссылками на другие каталоги. Теперь браузер файлов с соответствующим включением будет проверять файл с именем .readmeвсякий раз, когда он отображает каталог. Если он существует, его содержимое анализируется и отображается в ненавязчивой панели рядом с виджетом пути каталога. Можно щелкнуть любые ссылки в нем, и пользователь будет перенаправлен в целевой каталог этой ссылки.

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

Итак, вопрос: такая вещь существует? Если нет, то почему нет? Люди думают, что это стоящая идея?

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

Настройте, никогда не меняйте

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

Используйте описательные и последовательные имена каталогов

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

Написать документацию для вашей структуры каталогов

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

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

Существует ли такая вещь?

Нет, я так не думаю.

Если нет, то почему нет?

На мой взгляд: для небольшой статической иерархии с несколькими пользователями это излишне. Для большой изменяющейся иерархии со многими пользователями это не будет работать, потому что идея категорий (= каталоги, папка) не масштабируется.

Люди думают, что это стоящая идея?

Хм, это интересная идея. Чтобы увидеть, будут ли люди его использовать, кто-то должен это реализовать. Вместо .filingфайла вы можете хранить эту информацию в альтернативном потоке данных (да, в папках тоже может быть ADS). Вы можете использовать расширенные атрибуты в Linux и OSX. Самой большой проблемой, вероятно, будет исправление файловых браузеров.

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

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

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

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

Вы не указываете свою ОС, но есть отличные (и бесплатные) продукты, такие как alfresco, которые могут быть полезны вам лучше, чем ваши текущие настройки.

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

Сценарий выступает в качестве системы управления файлами, системы поддержки принятия решений и живой документации иерархии файловой системы. Стандарт иерархии файловой системы Linux - это немного миф, если подумать, потому что между дистрибутивами очень большая разница. Однако большинству пользователей Linux / Unix не обязательно самим узнавать об иерархии файловой системы, поскольку существует различное программное обеспечение, установленное в системе, которое управляет иерархией стандартным образом (менеджер пакетов, инструмент конфигурирования и т. Д.). Различные прикладные среды также создают сценарии для управления своими каталогами, например, в django есть команды управления для создания нового проекта, нового модуля приложения или файлов миграции сквоша и т. Д.

Это дает дополнительное преимущество, заключающееся в том, что сценарий может создавать различные символические ссылки, если файл нужно искать более чем одним способом, например, индекс, основанный на авторе файла или дате создания, или любое другое бизнес-правило, которое у вас есть. Вы можете смоделировать тегирование с помощью символических ссылок. Тег - это просто символическая ссылка из tagsкаталога, поэтому это tags/mytag/myfileможет быть символическая ссылка на actual/myfile.

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

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