Чи існує це: стандартизований спосіб документування структури файлової системи

На роботі я відповідаю за підтримку організації цілого ряду різноманітних даних у стандартній файловій системі. Частина цього складається з розумною класифікацією (за подібністю, необхідністю, доступу для читання / запису тощо), але більша частина - це фактично її документування: які документи / файли / носії інформації повинні надходити куди, що не повинно бути в цьому каталозі, "про щось дещо інше, див. ../../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, чудово, потім помістіть його в цю папку та створіть це посилання, і тоді вам потрібно буде змінити інший файл, щоб записати, що ви зробили звіт за цей місяць тощо).