Russian Qt Forum

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

Это называется архив. Поместить файлы в архив можно архиватором.

Так же под ваше описание подпадает папка :D

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

Если сжатия не нужно, используй tar архивы. Их формат можно найти, как и написать простейшие [де]архиваторы.

на linux папки и файлы это одно и то же как бэ :)

PS простейший архиватор. Их дофига.

Ну я так понял задание именно "свои". Ну так берете и пишете (примерно час)

C++ (Qt)
struct MyTag {
 int mID;              // ID тега (пока только 'FILE')
 qint64 mTagSize; // размер тега
 QString mName;  // имя файла
 qint64 mFileSize;  // размер 
 QDate mDate;   // дата 
 int mFlag;        // флаги (напр read-only)
};
 

Например извлечь

- открываете файл архива и считываете MyTag. Имя не подходит - делаете seek на след тег. Подходит - считываете содержимое которое записано за тегом, устанавливаете дату и флаги для извлеченного файла. Остальные операции (добавление, удаление и др) столь же очевидны.

Igors, спасибо! не подскажете где можно по подробней почитать про "seek" (поиск и чтение данных из файла)

В букваре (Assistent). И не травмируйте форум такими квешнзами  :'(

При наличии в структуре поля mName в виде QString так просто считать/записать MyTag не получится.

Ну почему же. Сделать ему фиксированную длину аля 1024 символа.

Больше смысла нет - имя файла в W рубится на 1024 символах в длине пути. К такому каталогу ни одна программа не сможет обратиться.

PS в линуксе незнаю.

Это в ANSI-версиях функций. В Unicode-версиях (с суффиксом W) максимальная длина имени около 32000 символов.

to Serr500

Извиняюсь я конечно, но Unicode версии ОС Windows(W7) я незнаю. Однако я знаю, что если создать не совсем корректными методами каталог с путём/названием больше 1024, то эксплорер отказывается с ним работать, как и 95% программ. Удаление/открытие/обращение к файлу/каталогу прерывается.

Если даже шелл ОС не работает с такими папками, то... То нефиг так делать.

to Верес

Согласен. Однако, моё уточнение относилось к фразе
Всё-таки 5% программ может.  ;)

А такой версии нет. Просто большинство функций WinAPI с аргументами-строками имеют два варианта - ANSI и Unicode. Обычно используются стандартные хидеры M$, а в них имена функций - это макросы. Там FunctionName в зависимости от включенного/выключенного Unicode транслируется либо в FunctionNameA (ANSI), либо в FunctionNameW (Unicode).

Нууу... Скажем так - программы исключительно перестрахованных программистов, которыми пользуются перестрахованные программисты :D

Поэтому 2 поля длины  :)

Т.е. qint64 (кстати, почему тогда не quint64?) на длину тега с учётом возможной длины имени файла в 2^32 байт :)? Но ведь всё равно sizeof (MyTag) будет константой сколько полей длинны не клади :)

Ну винтов (или томов) вылазящих за long long пока не видно, а иметь знаковое значение удобнее

Задумка такая: считали ID и длину тега, смотрим интересен ли нам он. Нет - seek на следующий. Да - заглатываем имя и др информацию (обычной сериализацией). Т.е. использовать sizeof (MyTag) никто не собирается, Обычно считывается контейнер тегов (их заголовков) а там уже по месту.

Неоптимальное решение, ибо если в архиве тысяча файлов и нужный файл самый последний, то придётся про-seek-ать весь файл.
Для таких вещей обычно делается такая структура архива:
в начале файла храним указатель на индекс:
struct Header
{
   quint64 index_offset;
   quit64  index_size;
};
в MyTag нужно добавить quit64 offset;
далее друг за дружкой пишем файлы c сохранением позиции начала файла в MyTag::offset
и уже после них получаем Header.index_offset;
далее пишем MyTag's, заполняем Header.index_size;
далее встаём в начало файла и опять пишем Header.
При чтении считываем Header. По его данным получаем индекс. В индексе ищем нужный файл и получаем его смещение.

Почему бы не использовать zip-архивы, есть обертка для Qt - QuaZip (http://quazip.sourceforge.net).

Это часто называется TOC. Так были устроены еще незабвенные .wad файлы :) Однако Вы забыли упомянуть о минусе этого решения: уязвимость TOC. Если я начал писать (и уже затер ТOC) и тут рубанули свет - все накрылось.

Хм, а где гарантия, что всё не накроется при Вашем последовательном варианте? При современном устройстве дисковых подсистем что-либо гарантировать при отключении питания я бы не стал.

Ну так я тупенько пишу в конец файла. Сбой - ну да, последний тег invalid, но я могу это определить на следующем скане (размер не сбивается). Впрочем обе схемы (с TOC и без) достаточно популярны/хороши.

У меня есть такая задача. На каждом запуске/проходе приложение грузит N картинок (больших). Расходы на распаковку jpg, png и др. значительны. Используются имеджи в "прямом" формате (ARGB и др), так же как и QImage. Однако никто не гарантирует что файлы остаются неизменными - надо проверять и, если надо, перегружать. Как бы Вы кешировали загрузку?

Размер + timestamp.

Ну как определить что файл изменен - то ясно. Вопрос был как кешировать. Хотя если нет желания обсуждать - не настаиваю