Доработка архиватора ARJ под Linux

Уникальная возможность засветить своё имя в веках и помочь человечеству для программистов на СИ.

В старом уникальном своими возможностями архиваторе ARJ есть возможности (красивое создание инкрементальных резервных копий), которые нигде до сих пор красиво не реализованы (chapters).

Они мне понадобились и я готов выступить спонсором продолжения разработки.

Кодер также сможет добавить в привествие ARJ одну строку своей рекламы с указанием своего имени.

Исходный код можно взять здесь:

http://sourceforge.net/cvs/?group_id=49820

Нужно доработать код на Си (возможно ++. я не смотрел в точности на чём он написан) и доработать следующие вещи:

- поддержку архивов и файлов размером более 2 gb.

- корректное удаление произвольных chapter

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

http://sourceforge.net/tracker/?atid=457564&group_id=49820&func=browse

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

Вначале придумывается как это сделать, потом придумка утверждается мной и Андреем Беловым, а потом идёт кодинг.

В проект должна быть вставлена небольшая реклама спонсора (я сообщу позже какая именно).

Есть рекомендации и советы от администратора проекта Андрея Белова, который сможет помочь советом:

> ограничение на размер

> >архива?

В основном - в arj_arcv.c. Сейчас все позиции/размеры в файлах - это

long. Простое решение - повсеместный long long и замена "%ld", "%lu" в

спецификаторах printf'ов (см. resource/resource.txt) на "%lld", "%llu".

Идеологически правильный путь - использование типов fpos_t и внедрение

своей версии printf'а. Если платформа 64-bit, можно весь этот этап

пропустить - long уже 64-битный.

Далее, в архиве (рекомендую вооружиться описанием формата из UNARJ) есть

поля "сжатый размер" и "исходный размер" - compsize и origsize. Их мало

сделать long long'ами - нужно придумать аналоги hput_longword() и

hget_longword() для этих 64/128-битовых величин. Если совместимость со

внешним миром все-таки нужна, то есть три варианта записи этих полей в

заголовок:

1. Сначала писать в заголовки 32-битные compsize/origsize, а 64-bit

размер указывать после - тут проблема в том, что хвост заголовка уже

перегружен наспех добавленными полями atime/ctime.

2. Использовать extended header - потенциальные неприятности с

многотомными архивами.

3. Эвристический подход: использовать старые поля, но писать в них

delta-величины, как в UTF-32 или в MIDI. Этот вариант посложнее, но

самый совместимый и изящный. Если исходный несжатый файл больше, чем,

например, 0x7F000000 байт (но не 0x7FFFFFFFF - нужен запас 1-2% на

случай шифрования) - резервировать 8 байт под каждое поле, и первую

четверку писать со взведенным старшим битом. В заголовке самого архива

(формат - тот же, что и у заголовка файла) может храниться указатель на

хвост архива, соответственно знать о вероятности превышения размера 2G

нужно заранее. Для чего можно свериться с total_size и volume_limit.

Остальное - по мелочам. Есть довольно дурацкие константы

FIRST_HDR_SIZE_xxx, от которых пора избавиться. В arj_file.c убедиться,

что проверка на MAX_FILE_SIZE больше не срабатывает.

Вот такой примерный пересказ из TO-DO.TXT. ;)

> >и как организовать удаление промежуточных chapter'ов?

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

> >переходили в следующий.

> >скорее всего для быстрого удаления промежуточных чаптеров придётся ввести концепцию внешних чаптеров,

> >которые хранятся не в самом архиве, а во внешних файлах. типа: archiv.arj archiv.c00 archiv.c01

> >при удалении промежуточного внешнего чаптера последующие чаптеры должны переименовываться, чтобы номер был на единицу меньше

arj_user.c: process_archive(). Код весьма спагеттиобразный, но в

пределах своего знания реализации chapter'ов могу сориентировать, ежели

что.

> >и есть ли ограничения на размер архивируемого файла?

Да, те же 2G и по тем же причинам.

> Вы хотите, чтобы старые архиваторы могли распаковывать новые огромные

> >архивы с огромными файлами?

Нет, но если мы архивируем новой версией что-нибудь небольшое и

отправляем архив пользователю старого ARJ, он не должен ничего заметить.

Поскольку 99% архивов будут меньше 2G, а 80% используемых ARJ'ей - это

версия 2.41, то совместимость существовать обязана.