rPman

у tar нет поддержки многотомных архивов, идеологически если ее и реализуют то делят итоговый архив просто на части без какого либо формата (порядок в именах файлах)

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

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

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

погугли: web archive alternatives
там куча продуктов, но мне кажется они не такие крупные

сомневаюсь что такая узкая задача будет реализована, так как веб архив достаточно дорогое удовольствие.ю Что именно тебе нужно (что такое 'профильная заточка') у web.archive.org точно знаю есть api, возможно можно реализовать что то поверх него?

Отправка архивов на почту - худшая форма передачи данных, неужели нельзя по другому?

Автоматизировать - значит написать приложение, вариантов 100500, бери делай, это не сложно
Вот к примеру как отправить почту с вложениями с помощью PowerShell

Одновременно все пункты мне не известно какой архиватор умеет такое, но по отдельности можно собрать их разных утилит. Самые сложные пункты 2 и 3.

3 пункт есть к примеру у parchive, собственно отдельная утилита для разбиения на тома и добавления информации для восстановления.

Есть утилиты (например rdfind), создающие символические или хард линки для идентичных файлов, а уже после можно.

Т.е. упаковываете файл tar-ом (он умеет линки но не упаковывает), сжимаете его bzip-ом после разбиваете на тома parchive и все это через пайпы одновременно, минуя промежуточное хранение файлов на диске.

Утилита linux - file. поставляется с кучей стандартных тулкитов портированных на windows хоть msys от mingw хоть cygwin, хоть используйте штатную Windows subsystem for linux

Утилита в командной строке позволяет указать файл, выводит его mime type по содержимому.

Я вам уже ответил ранее.

Вы просто попробуйте пройтись по текстовому sql-дампу diff-ом, результат вас удивит, ни один архиватор так эффективно не ужмет.

Кстати сам по себе diff по sql не очень эффективный, но если воспользоваться специализированным инструментом, заточенным именно на выявление разницы в данных БД, то можно получить еще больший профит (т.е. патч будет равен ровно тем данным, что были изменены).

К сожалению готовые инструменты чаще всего затачивают под конкретную базу данных, и это явно будет не firebird. Посмотрите утилиты от dbForge data compare, возможно оно вам подойдет (правда оно для вашей задачи избыточно), кажется там была возможность подключиться к любой базе.

Совсем правильно, поищите программиста, который вам запилит command line утилиту именно для этой задачи, делов то на неделю кодинга, может меньше.

Попробуйте bzdiff или лучше по эффективнее по памяти vbindiff (или обычный diff для текстовых)

upd. оригинальная утилита сильно потребляет оперативную память, нужно искать версии не такие требовательные

Можно хранить первоначальную версию и потом серию последовательных патчей, недостаток - для восстановления последней версии потребуется последовательное принятие всех патчей, очень длительная операция (фактически при каждом применения патча копируется весь файл)

Когда то давно я на основе этого делал резервное копирование, а чтобы не пришлось через год сотни патчей применять, храню только последние N патчей, старательно подготавливая N+1 версию (применяя старый патч и сохраняя результат, удаляя старую версию)

У вас только два варианта - либо кодируйте цветом High Capacity Color Barcode что даст вам примерно пятикратную оптимизацию по площади, либо размещайте код ссылку вместо самого кода, но это не так интересно, само собой.

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

Все зависит от технологии хранении и передачи информации и типа архивов.
Например если torrent считать 'архивом' (это контейнер для нескольких файлов) то есть отличный поисковик btdigg.org ищет все торренты по их именам и файлам в них, публикуемых в DHT сети.

Любой крупный архиватор (без режима 'solid') собственно так и делает. тот же rar или 7z.
p.s. чем собственно tar не устраивает?