rPman

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

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

Или только если у вас есть многопользовательский доступ к данным, точне. у вас возможен одновременный доступ к базе из разных сессий. Т.е. можно пожертвовать целостностью структуры базы на случай сбоя (например учитывать такую возможность при чтении данных) за счет заметного ускорения ее работы, если у вас только один пользователь и одно подключение к БД в любой момент времени.

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

Не всегда имеет смысл городить транзакции (они дорогие с точки зрения затрат ресурсов БД), иногда достаточно блокировок, т.е. перед началом записи вы блокируете доступ ко всей таблице (это можно делать в не транзакционной базе) или даже к отдельным полям, и другие сессии, при попытке прочитать/изменить их будут приостановлены до разблокировки.

Сама связность данных конечно подразумевает что нужен контроль целостности но оно не обязательно, вы можете заложить в коде возможность неполного заполнения данных об объекте и следить за порядком изменения этих данных. Например вы сначала добавляете запись в таблицу 'родители', с количеством детей 0, затем добавляете в таблицу 'дети' запись об их детях, т.е. вместо одной транзакции у вас независимые две, в любой момент структура верна но между записями информация о детях родителей неверная (родители есть а детей нет), это очень короткий момент и он точно не актуален если у вас всего один пользователь, пока он меняет информацию, никто другой не будет читать эти неверные данные.

Перенести home это наименьшая из проблем. Главная проблема обновлений между релизами - перенос системных настроек, когда меняются даже не версии программ а сами программы (подсистема запуска служб, например, а у вас там 100500 своих рукописных напихано). В этом случае придется вручную все это поднимать заново.

Если не обновлять, перестают работать штатные репозитарии, т.е. система работать будет но установка новых программ может быть затруднена, помню у меня работала то ли 14-ая версия то ли 12-ая (причем работало все хорошо пока диск помирать не стал), вот обновить их уже была проблема, штатные службы обновления не работали (нужные адреса уже не отдавали ожидаемые скрипты), в теории можно было бы поднять свои репы всех промежуточных ревизий и последовательно обновляться, но реально проще было переустановить с нуля.

Ищите сигнатуру rar, затем читая файл с э того места записывайте его в новый с нужным именем.

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

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

Chrome Remote Desktop - расширение к браузеру, которое позволяет получить доступ к машине пользователя вне браузера, т.е. какой то api на это имеется, изучите его или код расширения, хотя бы сможете реализовать задуманное в виде плагина.

Для firefox или safari стандарта на это вроде бы нет.

p.s. но зачем так извращаться?

попробуйте css селектор :not(div)
например
site.ru##div > :not(div) > div