Android 4.x.x это реально очень старая ОС. У меня из таких остался разве что Pixus Player. И то это не телефон а медиаплеер. Сомнительно что кто-то вообще поддерживает совместимость с такой стариной.
Хороший скрипт. Я думаю что это солюшен.
Но мне как программисту очень не нравится вот это временное имя "file_new".
Нет гарантий что мы не грохнем полезный файл. Вобщем надо-бы генерировать
случайное имя.
Самый популярный сигнал это kill -9 или kill -KILL.
По аналогии можете посмотреть man kill. Там широкаая спека сигналов. Штук 10 кажется. Среди таких я использовал несколько раз приостановку процесса. С целью потом послать сигнал CONTINUE чтобы возобновить. Есть еще команды на дамп памяти процесса. Полезно в отладке для тех кто шарит как разбирать дампы и понимать что там к чему.
Билд делается один раз. Обычно разработчик это делает. Потом делают push в удаленный регистри. Указывают версию. Тег. В registry появляется образ всей системы (приложения в данном случае). После этого на проде можно поднять новую версию по указанному тегу. Вообще я думаю схем развертывания может быть много. Но на проде никаких компилляций обычно не делают.
Похоже ты пытаешся автоматизировать развертывание проекта.
Обычно для этого есть всякие билд-средства такие как make, ant, maven, gradle, sbt (тысячи их)
Начинать с shell-скриптов тоже можно, но рано или поздно ты придешь
к использованию сборщиков.
В чем причина, и как можно эффективного сжимать близкие по содержимому большие файлы?
Несколько лет назад я интересовался таким подходом. Взять два бэкапа БД и выявив различия в блоках сделать - некое сжатие на основе дедупликации.
Пробовал утилиты наподобие bsdiff bsdiff: usage: bsdiff oldfile newfile patchfile
но они работают очень медленно т.к. расчитаны не на бэкапы баз а на изготовление бинарных патчей к
приложениям. Например там поправить 2 байтика в exe-шнике размером 50 Мб - это как раз самое то.
Попробуйте может вам способ подойдет. Но мне кажется что bsdiff не знает с чем имеет дело и поэтому
работает на уровне байтов хотя для бэкапов Postgres можно было искать различия на уровне 4-К страничек
или что-то в этом роде.
Опять-же такая природа может быть характерна для PG датафайлов но никак не для сжатых дампов. После
сжатия подобная блочная структура будет уничтожена.
Поэтому в идеале нужно делать копию дата-файлов. Потом блочый bsdiff. И только потом сжатие дельты
и сжатие первой копии.
Один парень в youtube красиво решает похожую задачу в С++ и многих других языках. Даю его решение. Хотя не уверен что автору оно подходит в силу особенностей. Может эта лаба должна демонстрировать базовые возможности С++.
Обычно о резервном копировании говорят применительно к какому-то кейсу. Например базы данных копируются по другому. Горячий. Холодный. И вариации (полный, инкрементальный, кумулятивный). Обычно БД знает о том что ее копируют. Или сценарий это позразумевает.
Файловые системы и файловые хранилища такие как (Btrfs, Zfs) умеют делать снапшоты. Снапшот - это почти нулевая по стоимости операция. Но она фиксирует некое замороженное состояние всех-файлов и позволяет копировать все по состоянию на эту точку во времени. Со снапшотами можно копировать работающий диск так что пользователи об этом даже не догадываются. Они работают как и раньше.
И эти пункты гораздо важнее чем разница между логическим копированием и образом. Базы тоже можно копировать образами. Только надо корректно завершать их работу. И копировать не только дата-файлы но и конфиги, инфраструктуру (control-files for Oracle).
Нужно на данные глянуть. СЛАУ могут не решатся по причинам отсутствия корней или по причинам наличия бесконечного множества корней. Как Гаусс-Зейдель на них реагирует - черт его знает. Но должна быть формальная проверка.
