Здравствуйте!

Имеется кучка файлов, которые можно поделить на две группы
1) длинные текстовые- например, лог 6 мегабайт ежедневно
2) куча коротких текстовых - например, ежедневно директория с 1440 файлами по 200 байт (ежеминутные данные)

Хочу их заархивировать с целью:
группа1 - чтобы уменьшить размер (важно при передаче)
группа2 - чтобы уменьшить количество файлов, просто склейка в один файл без сжатия уже подходит (то есть что-то типа tar уже достаточно) - важно для хранения.

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


Вопрос: есть ли примеры решения таких задач? аппноты какие-нибудь, блоги, линки....
Обычно на МК решается обратная задача - разжать (прошивку, образ итд), да и то из нестандартного формата, а вот упаковщики в "стандартный" архив как-то не попадаются.

Ни и если кто-то может рассказать про личный опыт, что за архиватор применяли на МК, буду безмерно счастлив.

конкретно буду реализовывать на STM32F4, если это важно

Ну так они не внавал миллионами лежат, а по дневным дирректориям, в каждой 1440 файликов. В момент копирования нового файла "в архив" тормозов сильных нет, всего-то 1237-й файл в известную дирректорию добавить.
Тормоза только после включения и ежесуточно, когда система проверяет все архивные фолдеры на предмет "а кто тут старее чем указанное в конфиге время жизни для этого типа файлов?" и удаляет старые. Вот это да, закат солнца вручную. (кстати, мой контейнер и этому горю поможет). Но это одна из задач многозадачки, так что не критично -остальное бегает в параллель.

А что сомнительно? я не вижу слабых мест при использовании FAT в виде иерархической структуры: большого числа файлов, распиханного по дирректориям.
Вот в Линуксе с его единой таблицей inode есть потенциальные грабли насчет количества файлов. Но там скрипты подтирают- принятый файл сразу после затягивания в базу данных добавляется в архив и удаляется. Как-то слетел скрипт - так inode на FTP была забита за неделю

Я с Вами полностью согласен, так нужно делать, когда это возможно. Но сильно не хочется свою утилитку делать (не только из-за лени). А еще больше "попонтоваться" хочется: "ну что, конкуренты коллеги, у меня zip, а у вас?"

Для подобных задач уже надо использовать пром. компьютер с "настоящей" осью, в которой уже все упаковщики работают "из коробки", а если инфа еще и важная, то есть смысл и raid прикрутить или в базы данных скидывать...

Перепроверил: у ISO большой заголовок на диск, и он хранится в теле этого iso файла. Плюс минимальный размер сектора - 2 килобайта, и каждый файл в своем секторе. В результате стоимость входа 50 килобайт, плюс по 2 килобайта на файл.
В-общем, это как переход от одной операционки к другой, выигрыша по занимаемому месту нет никакого так как нужно хранить файловые таблицы и файлы квантуются сектором 2К.

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

В-общем, реализовал tar с дописыванием в архив новых файлов по нужде. Имею желание в будущем добавить gzip и получить tgz.

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

Кстати, с Таром тоже хватило эротики- описание только на первый взгляд понятное, пришлось и в исходники за деталями залезть, а они не самые простые. Первые(простые)- не годятся, так как формат поменяли по дороге, по этой же причине в интернете разброд и шатание, могу найти противоречащие друг другу описания.
Более того- разные программы дают разный файл, и по хедеру и по длине, например ТоталКомандер и 7-zip, но не отказываются раскодировать файлы друг друга- видна повышенная толерантность и пофигизм к содержимому неосновных полей хедера и финальному маркеру (7Zip- лучше, я не нашел отклонений от описания в полученном с его помощью файле).

следующий виток- gzip, но тут вроде есть готовое, хочу попробовать mini_gzip

Я применила для такой задачи (сбор и ежесуточное архивирование данных) х86-совместимый пром.компьютер под Linux.
Для задачи попроще (файл был один) на STM32F103 применила архивaтор XZ Embedded

Так мне и надо было распаковать 1 файл на МК.
Если надо упаковать, есть библиотеки:
1. miniz
2. liblzf

Похоже ничего нового в этом мире нет.
Перепевки все тех же алгоритмов предложеных в начале темы.
Но по условиям темы вы должны еще показать достаточно распространенный разархиватор на PC для указанных форматов.

miniz пишет ZIP файлы.

При компиляции релиза liblzf получается (рас/у)паковщик в виде бинарника lzf которым элементарно просто пользоваться.

Может быть использовать не архиватор, а файловую систему со сжатием, например NTFS?
Исходники ntfs-3g бесплатны, открыты. А за деньги можно приобрести NTFS Embedded

Сообщение отредактировал firew0rker - Dec 7 2016, 09:01

Да можно много барахла найти по всяким свалкам исходников, никто не спорит.
Но во первых вы даже видимо не смотрели сколько памяти требует этот miniz, а во вторых видимо думает, что в STM32 есть такая же файловая система как в линуксе.

Не только барахла, много ценного тоже нарыть можно.
На STM32 можно работать и с файловой системой как в Линуксе, и с самим Линуксом!

Спасибо, но на линукс ради архиватора переходить не стану в данном устройстве.
У меня этот архиватор- задача опциональная, так что революцию в архитектуре не планирую, причин нет. Вот tar был необходим, это да, но он красиво лег и на то что уже есть.
Я поскреб по сусекам- наскреб у себя около полмегабайта РАМа, который смогу архиватору "во временное пользование" выделять, думаю это сильно расширит горизонты. Но вот нерезиновое ПЗУ экономить все равно нужно.

И, к слову, называль Линуксом uClinux - ну, у меня лично язык не поворачивается. Все ж таки MMU нужно, чтоб Линуксом назваться. И я с uClinux наигнался в его Блекфиновской инкарнации, и драйверы свои писал в него к моему железу тогдашнему, и оно даже работало. Как-то работало. Очень "как-то". И то был Блэкфин, а не свистелка STM32.

Вопрос к ТС-у:
Как я понял Вы остановились на tar? И уже имплементировали его?
У меня сейчас в чём-то сходная задача: нужно в прошивку устройства добавить содержимое некоего HTTP-сервера. И я тоже искал контейнер, чтобы объединить все файлы в один файл, из которого уже можно находить нужные отдельные файлики внутри firmware. Вопрос о сжатии пока не стоит.
Я посмотрел на tar, но мне показалось, что у него большой оверхед на всякие заголовки и т.п.
И я остановился на cpio. Вы его рассматривали? https://habrahabr.ru/post/130092/
Утилитка для него есть и под винду.

Да, сейчас я использую tar.
Нет, я не рассматривал cpio, так как не думал о нем как о "стандартном" упаковщике.
Очень может быть, что cpio лучше. По оверхеду он явно лучше, но может есть какие-то хитрости.