Доработка архиватора 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, то совместимость существовать обязана.