Как это устроено

Технические особенности реализации и общий принцип работы Attic: как клиент понимает, что файл изменился, что уходит по сети и что происходит, если один и тот же файл поправили на двух устройствах одновременно.

Клиент и синхронизация

Клиент следит за выбранными папками через системные уведомления файловой системы, а не опросом по таймеру — событие «файл изменился» долетает почти сразу. Перед отправкой файл режется на блоки фиксированного размера, для каждого блока считается хэш, и на сервер уходят только блоки, которых там ещё нет. Для большого файла с точечной правкой это разница на порядки — пример ниже.

Пример: сколько трафика уходит при правке

Правка одного абзаца в документе «Отчёт.docx» размером 18 МБ — при обычной синхронизации файл выгружается целиком, при синхронизации по блокам передаются только изменённые куски.

Сравнение объёма трафика: полная загрузка файла и синхронизация по изменённым блокам Загрузка файла целиком — 18 МБ. Синхронизация только изменённых блоков — примерно 340 КБ. Отчёт.docx, 18 МБ, изменён один абзац 0 6 МБ 12 МБ 18 МБ Целиком 18 МБ По блокам ≈340 КБ

Порядок цифр — по размеру блока и типовой правке текстового документа; точное число зависит от формата файла и того, что именно изменилось.

Шифрование и хранение

Блоки шифруются на сервере перед записью на диск, передача — только по TLS. База метаданных (какие блоки образуют какой файл и в какой версии) отдельная от самого блочного хранилища — так проще делать бэкап метаданных чаще, чем бэкап самих файлов.

Конфликты версий

Если один файл поправили на двух устройствах до того, как они успели синхронизироваться, сервер не пытается слить изменения сам — он сохраняет обе версии и помечает конфликт. Клиент показывает обе стороны и даёт выбрать, либо сохранить одну версию как основную, а вторую — рядом с пометкой в имени. Тихого выбора «сервер решил за вас» здесь нет.