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

11

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

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

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

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

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

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

jameshfisher
источник
Поскольку вы упоминаете об улучшении файловой системы (или файловых браузеров для конкретной файловой системы), особенно в отношении исходного кода, то также стоит упомянуть столь необходимую функцию упорядочения файлов . Большинство файловых систем имеют два основных типа упорядочения: алфавитный и несортированный. Но как насчет указанного пользователем заказа? Например, в случае исходного кода, если у вас есть 7 файлов (классы, модули, компоненты) в папке (модуль, пакет, родительский компонент), то их «логический» порядок обычно не совпадает с алфавитным порядком. Но скорее это порядок их «дерева зависимостей».
Сорин Постельнику
Таким образом, как стандартные дополнения к современным файловым системам, эти три функции должны присутствовать по умолчанию: 1) описания файлов, 2) пользовательский порядок файлов внутри папки и 3) тегирование / маркировка файлов. Не нужно использовать CMS для того, чтобы воспользоваться этими 3 «основными» функциями.
Сорин Постельнику

Ответы:

5

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

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

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

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

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

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

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


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

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

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

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

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

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

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

Людвиг Вайнцерль
источник
1
«Нет ничего хуже, чем постоянно меняющаяся структура файловой системы», за исключением той, которая решительно отказывается меняться, даже если структура больше не имеет смысла.
jameshfisher
1
«Используйте описательные и непротиворечивые имена каталогов» - абсолютно необходимо, да. К сожалению, существует конфликт между описательностью и краткостью - никто не хочет вводить путь к файлу в / srv / all -ierarchical-data / available-only-by-office-and-admin / letters-but-not-public заметки / учебный год-2009 / ... и так далее.
jameshfisher
«Написать документацию для вашей структуры каталогов» - тоже отличная идея. По сути, это то, что я предлагаю; просто документация будет распространяться, а не монолитна.
jameshfisher
«идея категорий (= каталоги, папка) не масштабируется» - правда, за исключением того, что иногда это просто необходимо. Скажем, большие исходные коды программного обеспечения ( git.kernel.org/?p=linux/kernel/git/next/linux-next.git;a=tree ).
jameshfisher
«Вместо .filingфайла вы можете хранить эту информацию в альтернативном потоке данных (да, в папках также может быть ADS). Вы можете использовать расширенные атрибуты в Linux и OSX». Возможно, я думаю, но это уменьшает мобильность и прозрачность, что я считаю очень важным. Что если я захочу разместить все в git-репо? Открытые текстовые файлы используются для специфической для каталога конфигурации (например, htaccess), так почему бы и не документировать?
jameshfisher
2

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

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

user3276552
источник
1

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

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

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

p.marino
источник
Я работал с различными CMS, но обнаружил, что переносимость, простота и прозрачность - огромные затраты по сравнению с самой почтенной CMS: деревом каталогов. Большая часть данных, которыми я должен был управлять, может вписаться в иерархию. В крайнем случае, есть символические ссылки. И структура каталогов иногда является единственным решением: например, при разработке программного обеспечения исходный код в своей основе представляет собой дерево каталогов. (Документирование таких каталогов, как правило, означает придерживаться жесткой и загадочной схемы, которая, в конечном счете, выходит из
строя
Как я уже сказал, ваша идея имеет свои достоинства, но я, как и автор другого постера, думаю, что она не может выходить за рамки данного уровня. Вы упоминаете исходный код, но это очень специализированный случай - и когда вы добавляете в него код, вы не заглядываете в существующие каталоги, чтобы найти, где он должен «соответствовать». CMS обычно дает вам возможность маркировать материал, чтобы у вас были «каталоги» (папки, пробелы, страницы), которые работают как ваше решение, плюс система тегов, позволяющая людям находить материал без необходимости искать «правильный» каталог. Это более гибко, чем символические ссылки и менее подвержено ошибкам, ИМХО.
p.marino
1

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

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

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

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

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

Ли Райан
источник