[C++/Qt] Работа с файлами при создании бэкапа

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

Меня волнует тот момент, когда во время копирования он изменится и в копии нарушится его структура. Пример - безсерверная БД вроде SQLite или BerkeleyDB.

Либо локи. Либо возможно ОС по моментальному snapshot'у

> Либо локи.

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

Либо возможно ОС по моментальному snapshot'у

Не совсем понял, о чём именно идет речь. Поясни, пожалуйста.

Ну в некоторых файловых системах есть возможность сказать: снимика мне sanpshot этого файла (или всего диска) и далее работать с ним - он гарантированно не будет изменяться

Вот только есть одна проблема: нет не какой гарантии, что в момент снятия данных эти саммые данные находятся в консистентном состоянии

Сейчас придет изя и пукнет про zfs. :)

Значит я правильно понял. Нет, этот вариант делает привязку к определённым ФС, что очень-очень плохо.

да какая нафиг фс. просто процесс который пишет в этот файл перед записью должен проверять рядом есть файлик lock или нет, если есть, то атата писать низя.

а бекап софтина перед копией делает файлик lock а после работы удаляет его. вот и вся магия. А если нужна непрерывная запись то используй фокусы с Фс или ЛВМ.

Проблема в недобросовестных разработчиках, которые не лочат файл перед записью. А ещё lock-файл может лежать в /tmp или /var/run и ещё где-то.

а бекап софтина перед копией делает файлик lock а после работы удаляет его.

Также не вариант. Ибо а) некоторые разрабы не используют локи; б) бэкап не должен мешать работе программ (ибо локировка файла - это не локировка БД)

А если нужна непрерывная запись то используй фокусы с Фс или ЛВМ.

Привязка с ФС или ЛВМ - не выход, это сродни уничтожения сорняков Буратиною.

Нормальные БД позволяют делать онлайн бекап без остановки работы с базой.

и да ТЗ нормально сформулированное в студию, хватит гадать на костях черепах что тебе надо.

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

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

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

> Либо возможно ОС по моментальному snapshot'у

Чем это поможет? ОС ничего не знает о внутренней структуре файла следовательно ОС не сможет угадать момент для снапшота так как не знает когда файл консистентен с точки зрения его логической структуры.

Да. Я позже сделал комментарий по этому поводу. Ступил с формулировкой

Буду краток: Acronis.

> Нормальные БД позволяют делать онлайн бекап без остановки работы с базой.

Я это знаю, но в данном случае ПО для бэкапов вообще не в курсе, что там за файлы храняться и являются ли они БД. Достаточно вспомнить Firefox, Skype, Clementine/Amarok, digkam, и пр., которые хранят свои данные в тех же SQLite/BDB.

ТЗ

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

В вашем случае как раз надо механизм снапшотов, LVM вас в этом поможет.

Это сильно сузит доступную область применения ПО. Ладно, наверное, надо будет узнавать, есть ли открытые дескрипторы файла, и мониторить их наличие при операциях.