Итак что хотелось(некое ТЗ):
1) Дедубликация файлов. Идеально подойдет для большого числа мелких файлов. Т.е. вместо двух одинаковых файлов /some_dir/fileA и /some_dir/long_long_path_toFile/fileZ физически храниться будет только 1 экземпляр, причем независимо от названия файла и то где он расположен в разных версиях или пределах одной.
2) Названия файлов для раздачи(т.е. url в будущем) должен быть предельно коротким без спецсимволов.
3) Некоторая примитивная защита некоторых файлов. Т.е. тупо уникальное имя файла при загрузке которое сложно будет подобрать.
4) Некий список файлов по которому их нужно загружать.
5) Какая либо стандартизация служебных файлов.
6) Примитивный контроль целостности файла. Используется как для проверки целостности контента на сервере в ФС, так и у клиента для возможности сравнения его текущего контента с серверным и осуществлять выборочную загрузку только измененных файлов а так же проверки целостности локального контента.
7) Возможность сжатия файлов для еще большей экономии места на сервере и меньшего размера при передачи клиенту.
8) Отсутсвие активных фремворков\демонов\сервисов на сервере, только чистый nginx или cifs для возможности своей обвязки из вне при необходимости.
9) Работа софтинки которая все это проворачивает на linux\win и возможностью переноса данных между ними.
Решение:
1) При заливке файла на хранение считается его sha1 и переименовывается в саму сумму.
2 и 3) Грубо говоря .../storage/первые_2_символа_хэша/хэш. Т.е. для примера /storage/65/65586BD072DD6DEF8DADCDEB66C110390C41B4C7. Прослойка в виде папки с названием первых 2х символов лишь для того чтобы избежать возможных коллизий или багов хостовой ФС(ntfs\fat\extX) т.е. просто перестраховка.
4 и 5) При заливке файла создается json файлик со структурой в которой хранится полное название файла вместе с его путем и его хэш сумма.
6) Алгоритм sha1 которым можно проверить целый ли файл и соответсвует нужной сборке\билду.
7) Тут все просто , любые свободные алгоритмы lzop, gzip, bzip2, xz и т.д. Но об этом позже.
8) Тут вытекающее решение было в п2.
9) Java.
Что есть прям сейчас? п1-2-3-4-5-6-8-9.
п7 пока отложил банально потому что есть идея обернуть все это добро в fuse(виртуальная файловая система в слое пользователя) и для начала надо будет проверить быстродействие таких решений да и вообще надо ли оно кому либо?
Какие варианты применений:
1) С чего все и началось, а именно тупо доставка контента через сеть малыми порциями с контролем целостности и вариантов апгрейда\даунгрейда.
2) Лютая экономия места на винтах при условии что контент от версии к версии меняется и самих файлы небольших размеров.
3) Если прикрутить через FUSE то можно и локально неплохо экономить.
Как живой пример:
Берем кучи билдов сталкера, обязательно распаковываем игровые архивы и все пушим в эту виртуальную ФС, на выходе получаем экономию места равную числу одинаковых файлов.
Другой пример если вы делаете какойто мод, то можно доставлять патчи наживую автоматически всем клиентам.
Если же прикрутить fuse то люто сэкономив место на диске можно запускать любой билд =)
Сейчас есть полностью готовая альфа софтинки которая умеет, разворачивать такой репо, принимать новый контент, удалять(не повреждая другие снимки) другой контент, вытаскивать контент обратно в обычный вид. Пока не готов универсальный лоадер этого добра но это не так сложно.
Утилита консольная со своим cli. Пара скринов с примером работы и небольшим описанием команд.
Скрины
?l вывести все доступные команды.
dir -без аргументов показать путь до рабочего каталога(собственно там где все барахло будет храниться)
dir путь_до_каталога - с аргументом, указать новый рабочий каталог.
make название_снимка путь_до_директории - 2 аргумента, внести новый снимок с заданным именем(имя служит частью уникальности но может повторяться, полная уникальность происходит за счет имени и даты снимка)
list - вывести список всех снимков. (name)название (date)дата и самое важное (fullname)уникальное название под которым софт видит и работает со снимком.
restore название снимка путь_куда_развернуть - 2 аргумента, вытягивание снимка контента в указанный каталог. Название может быть только как имя (secondPush) или даты (20-09--23-01-2018) или полного названия (20-09--23-01-2018-secondPush). В случае если вы укажите только название к примеру (secondPush) но окажется что под таким именем их несколько то она скажет что их несколько и необходимо полное уникальное имя
delete название_снимка - 1 аргумент, безопасно удалить снимок с заданным именем. Название может быть только как имя (secondPush) или даты (20-09--23-01-2018) или полного названия (20-09--23-01-2018-secondPush). В случае если вы укажите только название к примеру (secondPush) но окажется что под таким именем их несколько то она скажет что их несколько и необходимо полное уникальное имя.
*Тут немного мусора в выводе, потом уберу.
Пример файла с описанием снимка.
Т.е. url будет для скачивания будет вида
CODE
{
"vfs_version": "01",
"name": "secondPush",
"date": "Jan 23, 2018 8:09:08 PM",
"files": [
...
{
"path": "|logs|fml-junk-earlystartup.log",
"hash": "737bdc7ac561d642ce3a4d715cf9c668ae1dd001"
},
{
"path": "|logs|latest.log",
"hash": "c156f981e913bfcec5b00edc4d8ae51eba8898c2"
},
{
"path": "|logs|shadersmod.log",
"hash": "6fb36bd7d14093ac9eb329b31145830182a6f6e8"
},
{
"path": "|test_net.exe",
"hash": "d1a6a930d69cf6ae3c4ad14db40c49a3120bb347"
}
...
}
Пока все сырое но работает, нужно тестить, куча орфографических ошибок. Названия команд и их описание от балды на скорую руку.
Что хочу узнать:
1) Оно комунибудь нужно еще кроме меня?, т.к. я своей цели достиг для другого проекта.
2) Посоветуйте нормальные названия команд для cli =)
3) Нужен ли gui?
4) Нужен ли командный режим аля софт.exe -команда -команда5 -командаN
5) Нужен ли какой то простой универсальный лоадер\апдейтер клиентский. Что то типа указал json ,указал URL откуда, указал куда качать. Типа для удобства или кому надо проще написать самому т.к. json схватить везде можно и в общемто ничего сложного тянуть по http нет?
Ну и ссылка на софтинку
PS по идее ничего плохого наломать не сможете, по крайней мере проверял все много раз но на всякий случай я не виноват