[Comm] Мысль по поводу организации общего файлохранилища (для обсуждения)

[Денис Черносов]

Навеяно вот этой статьей и экспериментами с Ruby On Rails и
вдохновением от wiki-технологий:

http://www.calculate-linux.ru/%D0%9E%D1%80%D0%B3%D0%B0%D0%BD%D0%B8%D0%B7%D0%B0%D1%86%D0%B8%D1%8F_%D1%85%D1%80%D0%B0%D0%BD%D0%B5%D0%BD%D0%B8%D1%8F_%D1%84%D0%B8%D0%BB%D1%8C%D0%BC%D0%BE%D0%B2

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


Причины:
1) отсутствие общепринятых паттернов файловой иерархии для большинства
случаев (включая соглашения об именовании файлов и каталогов и
разделения доступа к ним). Их не предлагают по умолчанию в таких
продуктах, как Samba или Nfs (примеры настройек для папок верхнего
уровня не в счет - это просто специализация файлопомоек) и этому не
учат ни в школах ни на курсах. Замкнутый круг - культуры нет, потому
что её нет нигде.
2) отсутствие автоматических средств для быстрой организации
умолчальных деревьев каталогов, выставления прав на них, заполнения и
актуализации метаинформации о содержимом каталогов, автоматическом
перемещении, переименовании, удалении файлов и каталогов. Нет смысла
обвинять пользователей в том, что они не хотят выполнять изо дня в
день работу более подходящую для роботов.

При наличии формализованных соглашений, становится возможным создание
скриптов на все случаи жизни (как это сделано в Ruby On Rails).
Остается только один вопрос - как, не порождая новых сущностей (хотя
бы на стороне клиента) и зависимостей реализовать это на базе samba,
nfs, ftp.
Очевидно, через адресацию - несуществующий адрес воспринимается, как
команда и при осмысленности этой команды и наличии достаточных прав на
её выполнение - вуаля!
Что интересно - можно прикручивать этот модуль для отработки именно
несуществующих адресов, а это практически не повлияет на
быстродействие системы в целом. А в качестве доп. вкусностей еще
мечты: при наличии проблем, диагностическое сообщение (возможно с
предугадываниями, типа "наверное вы хотели вот этого" и/или
подсказками - "если хотите того, то начните сначала с этого").

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

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

Что скажете? Баян? Утопия?